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ABSTRACT 


Current  business  process  redesign  practices,  in  the  defense  sector  as  well  as  in  business  in  gen¬ 
eral,  are  based  on  several  assumptions  inherited  from  Taylor’s  scientific  management  method,  includ¬ 
ing  the  key  assumption  that  activity-flow  representations  should  provide  the  basis  for  business  pro¬ 
cess  redesign.  While  this  assumption  was  probably  correct  for  most  organizations  in  the  early  1900s, 
it  is  clearly  inconsistent  with  the  fact  that,  currently  “information”  is  what  flows  the  most  in  business 
processes,  even  in  manufacturing  organizations.  This  project  is  based  on  the  key  assumption  that  the 
current  focus  of  business  process  redesign  approaches  should  be  on  information  flows  rather  than 
activity  flows. 

The  main  goal  of  this  project  is  to  develop  a  methodology  for  redesigning  acquisition  processes 
based  on  knowledge  and  information-flow  analysis.  The  methodology,  called  InfoDesign,  focuses 
on  the  knowledge  embedded  in  a  business  process,  the  information  processing  resources  involved  in 
execution  of  the  process,  and  the  information  flowing  through  the  process.  The  InfoDesign  method¬ 
ology  was  developed  and  partially  validated  during  a  one-year  project.  The  validation  of  the  method¬ 
ology  was  conducted  as  an  action  research  study  in  which  one  acquisition  process  involving  the  U.S. 
Government  and  one  key  supplier  was  analyzed  and  redesigned.  The  results  of  the  study  support  the 
key  assumption  on  which  InfoDesign  was  built  —  that  current  business  process  redesign  approaches 
should  focus  on  information  flows  rather  than  activity  flows. 


ORGANIZATION  OF  THIS  REPORT 


This  report  is  divided  into  five  chapters.  A  description  of  each  of  these  chapters  is  provided  below: 

•  Chapter  I:  Research  Prohlem,  Goals,  and  Plan.  This  segment  of  the  report  discusses  the 
motivation  of  the  research  project  and  its  main  goals.  It  also  provides  details  about  the  project 
schedule,  main  deliverables,  and  potential  impact  within  the  defense  sector  and  elsewhere. 

•  Chapter  2:  Conceptual  Foundation.  This  segment  of  the  report  discusses  the  concept  of 
process  as  well  as  several  popular  views  of  processes,  with  particular  attention  to  the  data¬ 
flow  and  work-flow  views.  It  also  discusses  three  fundamental  concepts  —  data,  information 
and  knowledge.  This  discussion  is  particularly  important  because  of  the  rather  confusing  way 
in  which  these  terms  are  used  in  both  academic  as  well  as  more  popular  ways.  We  offer  new 
conceptualizations  that  suggest  that  data  is  a  carrier  of  information  and  knowledge;  and,  while 
information  is  eminently  descriptive,  knowledge  is  mostly  predictive  in  nature.  Although  these 
conceptualizations  are  heavily  based  on  previous  theoretical  frameworks  from  cognitive  sci¬ 
ence  and  artificial  intelligence,  we  tried  to  eliminate  technical  jargon  as  much  as  possible  and 
explain  our  views  through  examples  involving  simple  day-to-day  situations. 

•  Chapter  3:  The  InfoDesign  Methodology.  This  segment  of  the  report  discusses  the  InfoDesign 
methodology,  which  was  developed  as  part  of  this  project.  A  methodology  for  process  rede¬ 
sign  is  necessarily  made  up  of  guidelines  that  are  followed  by  those  employing  it.  Since  those 
guidelines  should  be  defined  for  each  step  of  the  methodology,  there  are  usually  many  of 
them,  several  of  which  may  appear  disconnected  and  coming  out  of  nowhere.  Given  this,  key 
principles  that  are  used  as  a  basis  for  the  creation  of  guidelines  are  discussed  in  this  chapter. 

•  Chapter  4:  The  Need  for  a  Shift  in  Redesign  Focus.  This  segment  of  the  report  argues  that 
current  business  process  redesign  practices,  in  the  defense  sector  as  well  as  in  business  in 
general,  are  based  on  several  assumptions  inherited  from  Taylor’s  scientific  management  method, 
including  the  key  assumption  that  activity-flow  representations  should  provide  the  basis  for 
business  process  redesign.  It  also  argues  that  the  current  focus  of  current  business  process 
redesign  approaches  should  be  on  information  flows  rather  than  activity  flows.  This  point  is  at 
the  source  of  the  development  of  the  InfoDesign  methodology. 

•  Chapter  5 :  Validating  InfoDesign  through  an  Action  Research  Study.  In  this  chapter,  the 
point  made  in  Chapter  4  is  formalized  by  means  of  a  hypothesis,  which  is  tested  through  an 
action  research  study  of  a  business  process  redesign  project.  The  project  results  in  the  redesign 
of  a  software  development  procurement  process  involving  the  Department  of  Defense  (DoD) 
and  Computer  Sciences  Corporation.  The  study  supports  the  claim  by  showing  that  the  mem¬ 
bers  of  a  business  process  redesign  team  voluntarily  favored  the  use  of  InfoDesign,  which  is 
based  on  an  information-flow  approach  to  business  process  redesign  over  a  traditional  ap¬ 
proach  based  on  activity  flows. 
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CHAPTER  1 

RESEARCH  PROBLEM,  GOALS,  AND  PLAN 


Problem  Statement 

The  economic  environment  surrounding  organizations  in  virtually  every  industry  is  undergo¬ 
ing  change  at  a  pace  that  has  never  been  experienced  before.  This  is  caused  by  several  factors, 
including  the  fast  development  of  new  technologies,  the  emergence  of  new  competitors,  and  mar¬ 
ket  pressure  for  changes.  New  technologies  enable  increases  in  productivity,  customer  satisfaction, 
and  market  reach.  As  capitalism  spreads  throughout  the  world,  new  competitors  emerge  from  un¬ 
likely  quarters,  such  as  firms  from  other  industries  or  countries  that  were  not  previously  major 
competitors  in  world  trade.  Information  about  features  of  highly  competitive  services  and  products 
is  quickly  disseminated,  driving  market  pressure  for  change  (Kock,  1998).  These  forces  not  only 
push  suppliers  to  continuously  redesign  their  business  process  to  keep  their  acquisition  process 
effective  and  competitive  but  also  push  buyers  into  similar  patterns  of  change  so  they  can  take 
advantage  of  new  products  and  forms  of  delivery  (Davenport,  1993;  Deming,  1986;  Harrington, 
1991). 

In  addition  to  the  accelerated  pressure  for  change,  the  nature  of  work  has  become  more  com¬ 
plex  and  specialized  as  new  knowledge  is  continuously  created  and  incorporated  into  the  produc¬ 
tion  of  goods  and  services  (Davenport  et  ah,  1996),  mirroring  a  larger-scale  trend  towards  knowl¬ 
edge  specialization  and  fragmentation  (Hayek,  1996).  Products  and  services  are,  thus,  increasingly 
more  sophisticated  and  knowledge  intensive,  requiring  the  involvement  of  a  variety  of  experts, 
each  holding  a  key  piece  of  specialized  knowledge  to  be  produced  and  delivered.  It  has  been 
shown  that,  as  knowledge  becomes  more  specialized  and  fragmented,  the  information  flowing 
among  individuals  holding  different  types  of  expertise  increases  substantially  (Kock  and  McQueen, 
1996;  1998)  and,  in  many  cases,  leads  to  an  “information  overload”  (Evaristo  et  al.,  1995;  Kock, 
1999). 

Current  business  process  redesigning,  which  focuses  on  work  flows  (or  activity  flows),  is  incon¬ 
sistent  with  the  above  trends.  In  fact,  many  aspects  of  the  current  trend  have  been  referred  to  as 
modern-day  versions  of  older  techniques.  These  older  methods  include  the  mechanistic  methods, 
based  on  the  “time-and-motion”  analysis  developed  from  the  early  notions  of  Adam  Smith  (1910; 
1910a),  and  the  subsequent  development  of  scientific  management  methods  by  Taylor  (191 1).  New 
process  redesign  methods  are  needed.  These  new  methods  should  focus  on  knowledge  management 
and  information  flow.  While  their  main  goal  is  to  fill  a  methodological  gap,  these  new  methods  can 
complement  and  potentially  replace  existing  methods  based  on  work  flows. 

Goal  and  Approach 

The  goal  of  this  project  is  to  develop  a  methodology  for  redesigning  acquisition  processes  based 
on  knowledge-  and  information-flow  analysis.  This  methodology,  called  InfoDesign,  focuses  on  the 
knowledge  embedded  in  a  business  process,  the  information  processing  resources  involved  in  execu¬ 
tion  of  the  process,  and  the  information  flowing  through  the  process.  While  the  development  of 


1 


InfoDesign  is  one  of  the  components  of  this  proposal,  the  methodology  combines,  develops,  and 
refines  specific  aspects  of  one  previously  published  methodology  and  two  theoretical  frameworks 
listed  below: 

•  MetaProi  stands  for  Meta  Process  for  Process  Improvement  (Kock,  1999a).  MetaProi  is  a 
refinement  of  the  PROI  methodology  (Kock,  1995)  and  is  a  process  redesign  method  focused 
on  information-flow  streamlining. 

•  Theory  of  Constraints  (Bramorski  et  ah,  1997;  Goldratt,  1990;  Goldratt  and  Cox,  1986; 
Goldratt  and  Fox,  1986).  One  of  the  hypotheses  of  this  theory  is  that  a  focus  on  “bottlenecks” 
leads  to  optimal  business  process  design,  from  both  an  efficiency  and  effectiveness  perspec¬ 
tive.  Bottlenecks  are  defined  as  subprocesses  (or  activities)  that  pose  constraints  on  process 
cost  reduction  and  reduce  throughput.  In  other  words,  the  theory  hypothesizes  that,  if  process 
redesign  is  conducted  (based  on  the  identification  and  redesign  of  bottlenecks),  the  process 
will  be  accomplished  cheaper  and  faster  and  without  any  impact  on  process  redesign  quality 
than  if  no  focus  on  bottlenecks  occurs. 

•  Information  Load  Theory  (Evaristo  et  ah,  1995).  The  term  “information  overload”  has  been 
used  in  the  business  literature  without  first  considering  the  true  meaning  of  “information  load,” 
the  underlying  construct.  This  theoretical  treatment  suggests  that  there  are  several  antecedents 
of  information  load,  some  affecting  demand  for  information  processing  resources  and  others 
affecting  the  supply  of  these  resources.  “Information  load”  is  how  much  of  the  supply  is  being 
used  by  the  demand  for  these  resources.  In  particular,  knowledge  about  the  demand  anteced¬ 
ents  can  be  invaluable  in  controlling  the  level  of  information  load  and,  therefore,  the  potential 
performance  in  certain  tasks. 

InfoDesign  is  used  in  this  research  project  for  the  identification  of  “information- flow  bottlenecks” 
in  business  processes.  Building  on  MetaProi,  a  set  of  guidelines  is  developed  to  restructure  business 
processes  based  on  process  modeling  and  analysis  outcomes.  Information- load  theory  is  used  for  the 
preparation  of  these  guidelines  by  providing  a  conceptual  basis  for  the  optimization  of  information 
loads.  Part  of  the  objective  is  to  avoid  letting  the  load  become  too  low  or  too  high,  situations  that  are 
likely  to  lead  to  lower  performance  levels. 

The  InfoDesign  methodology  was  developed  and  partially  validated  during  a  project  lasting  ap¬ 
proximately  1  year.  The  project’s  main  tasks  and  subtasks  are  described  in  the  Project  Schedule  (see 
Appendix  A).  The  validation  of  the  methodology  was  conducted  as  an  action  research  study  (Checkland, 
1991;  Elden  and  Chisholm,  1993;  Kock  et  ah,  1997;  Winter,  1998)  in  which  one  acquisition  process, 
involving  the  U.S.  Government  and  one  key  supplier,  was  analyzed  and  redesigned.  The  process  rede¬ 
sign  proposal  was  cross-evaluated  for  quality  and  for  the  likely  organizational  impact  by  stakeholders  of 
the  organizations  involved.  This  was  performed  immediately  after  its  delivery  and  before  its  implemen¬ 
tation.  Six  months  after  the  delivery  of  the  process  redesign  proposal,  a  review  of  its  implementation  was 
conducted  to  assess  its  bottom-line  impact  on  process  efficiency  and  quality. 

The  following  table  lists  potential  suppliers,  who  were  initially  contacted  and  who  have 
partnered  with  the  researchers  in  previous  projects;  products;  and  respective  buyers  within  the 
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U.S.  Government.  We  eventually  partnered  with  Computer  Sciences  Corporation  and  Lockheed  Mar¬ 
tin  for  this  research  project.  Each  of  the  two  companies  contributed  a  group  of  employees  to  work  on  the 
redesign  of  a  software  acquisition  process  involving  the  Department  of  Defense  and  Computer  Sciences 
Corporation.  (Lockheed  Martin  often  partnered  with  Computer  Sciences  Corporation  to  develop  soft¬ 
ware  products.) 


Supplier 

Products 

Buyer 

(U.S.  Government) 

Computer  Sciences  Corporation 
http://www.csc.com 

Software 

U.S.  Navy 

Day  &  Zimmerman 
http://www.dayzim.com 

Munitions 

U.S.  Army 

Lockheed  Martin 
http://www.iockheedmartin.com/ 

Rockets  and  aviation 
equipment 

U.S.  Air  Force, 

NASA 

Concurrent  Technoiogies  Corporation 
http://www.ctc.com 

High-end  simuiation 
equipment 

U.S.  Navy 

Project  Deliverables 

This  project  has  one  main  deliverable  —  a  methodology,  which  is  described  as  a  set  of  activities, 
guidelines,  support  forms,  and  graphical  tools  for  redesigning  acquisition  processes.  (The  graphical 
representations  used  in  this  report  are  independent  from  current  computerized  process-modeling  tools.) 
The  main  stages  of  this  methodology  include: 

(a)  Process  modeling  that  is  focused  on  knowledge  distribution,  information  processing  re¬ 
sources,  and  information  flow; 

(b)  Identification  of  “information-flow  bottlenecks”  in  acquisition  processes; 

(c)  Information-flow  analysis  focused  on  the  bottlenecks  identified  in  stage  (b); 

(d)  Process  redesign  based  on  the  analysis  performed  in  stage  (c);  and 

(e)  Implementation  of  process  redesign  changes. 

In  addition  to  the  methodology  discussed  in  detail  in  this  report,  other  deliverables  include  a 
dissemination  web  site  and  several  publications.  These  are  described  later  in  this  chapter  under  the 
heading  “Dissemination  of  Results.”  This  final  report  includes  a  detailed  discussion  of  the  action 
research  study  used  for  the  validation  of  the  methodology,  conclusions,  and  suggestions  for  future 
research,  refinement,  and  application  of  the  methodology. 

Potential  Impact  and  Significance 

Based  on  the  amounts  of  money  involved  in  U.S.  Government  acquisition  processes,  it  is  clear 
that  even  small  improvements  can  result  in  large  savings.  We  expect  that  the  InfoDesign  methodol¬ 
ogy  will  contribute  to  such  improvements. 
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Due  to  resource  scarcity  —  not  only  physical  equipment  but  also  knowledge  and  human  re¬ 
sources  —  and  the  increasing  irrelevance  of  geographical  location  to  establish  a  business,  it  is  likely 
that  a  higher  percentage  of  projects  will  be  distributed  in  nature  in  the  near  future.  Therefore,  we  do 
anticipate  that  this  research  project  will  also  have  another  important  consequence  in  the  future.  Given 
the  emphasis  on  information  flows,  which  usually  occur  asynchronously  and  independently  of  geo¬ 
graphical  location,  the  knowledge  generated  by  this  research  project  will  be  particularly  useful  in  the 
redesign  of  acquisition  processes  involving  several  geographically  distributed  suppliers. 

Dissemination  of  Results 

The  results  of  this  project  are  being  disseminated  through  the  following  main  outlets:  A  support 
web  site,  two  conference  papers,  and  two  journal  articles.  The  conference  papers  and  journal  articles 
are  available  from  the  support  web  site  (the  versions  on  the  web  site  do  not  incorporate  editorial 
changes).  These  outlets  are  discussed  below. 

Support  Web  Site 

This  web  site  contains  a  description  of  the  project;  documents  developed  during  the  project, 
including  the  final  report  on  the  project;  and  several  multimedia  components  discussing  key  project 
issues.  The  web  site  is  available  at  www.mis.temple.edu/earp. 

Conference  Papers 

1.  Kock,  N.  and  Murphy,  F.  (to  be  submitted),  “Communication  as  the  Focus  of  Business  Process 
Redesign:  An  Action  Research  Study  of  Defense  Contractors,”  International  Conference  on  Informa¬ 
tion  Systems  [December  2001,  Boston,  MA]. 

2.  Kock,  N.  (submitted  Feb  2001),  “Web-driven  Management  Thinking:  A  Look  at  Business 
Process  Redesign  in  the  Age  of  the  Internet,”  IFIP  Conference  on  E-  Business  [October  2001,  Zurich, 
Switzerland]. 

Journal  Articles 

1 .  Kock,  N.  (submitted  Feb  2001),  “Changing  the  Focus  of  Business  Process  Redesign  from  Activity 
Flows  to  Information  Flows:  A  Defense  Acquisition  Application,”  Acquisition  Review  Quarterly. 

2.  Kock,  N.  (accepted,  forthcoming),  “Managing  with  Web-based  IT  in  Mind:  A  Simple  Frame¬ 
work  Based  on  Practice,”  Communications  of  the  ACM. 

3.  Kock,  N.  (2000),  “Benefits  for  Virtual  Organizations  from  Distributed  Groups,”  Communica¬ 
tions  oftheACM,\.43,  No.ll,  pp.  107-113. 

The  support  web  site  and  any  publications  based  on  this  project  leave  out  and/or  disguise  classi¬ 
fied  information  and  any  details  deemed  confidential  by  the  project  participants. 
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CHAPTER  2 

CONCEPTUAL  FOUNDATION 


Process  Views:  Focusing  on  Certain  Aspects  of  Processes 

As  a  concept  becomes  more  abstract  so  does  the  discrepancy  in  the  ways  different  people  con¬ 
strue  its  meaning.  A  concept  that  refers  to  a  tangible  object,  like  that  of  a  chair  for  example,  is  likely 
to  be  understood  more  or  less  in  the  same  way  by  two  people.  With  abstract  concepts,  such  as  those 
used  in  a  process,  however,  understanding  is  much  less  likely  to  be  achieved  without  further  clarifica¬ 
tion.  One  of  the  reasons  for  this  difficulty  is  that  abstractions  are  not  perceived  by  our  five  senses  as 
“real”  objects  (like  a  chair  that  we  can  see  and  touch)  and,  therefore,  must  be  understood  based  on 
abstract  models.  If  these  models  do  not  exist  or  if  they  are  too  rough  and  incomplete,  a  sense  of 
perplexity  often  develops. 

As  with  most  abstract  entities,  processes  need  to  be  modeled  so  people  can  understand  them  and, 
more  importantly,  so  two  or  more  people  can  understand  them  in  roughly  the  same  way.  Irrespective 
of  how  complex,  models  are  limited  representations  in  most  cases,  whether  of  real  objects  or  abstract 
entities.  A  representation  of  a  transistor,  for  example,  can  help  one  predict  how  it  will  behave  (e.g., 
amplify  an  electrical  input)  when  an  electrical  impulse  of  a  certain  voltage  is  applied  to  it.  Still,  the 
same  representation  can  be  almost  useless  when  predicting  the  operation  of  the  same  transistor  if  the 
input  is  an  alternating  current  with  a  frequency  above  a  certain  level  (e.g.,  as  in  analog  telecommuni¬ 
cation  circuits).  Similarly,  a  certain  representation  of  a  car,  such  as  a  diagram  in  an  owner’s  manual 
that  explains  the  basic  operation  of  the  car,  can  be  detailed  enough  for  someone  who  wants  to  drive 
the  car  yet  useless  to  someone  who  needs  to  repair  the  car.  In  fact,  perhaps  the  only  characteristic  that 
is  shared  by  all  models  is  that  they  are  all  incomplete. 

A  few  main  types  of  process  models  or  views  are  discussed  in  the  following  subsections.  As 
discussed  above,  these  views  lead  to  incomplete  representations  of  processes  and,  therefore,  should 
be  understood  in  terms  of  their  pros  and  cons  in  today’s  information-  and  knowledge-intensive  orga¬ 
nizational  environments. 

The  Work-flow  View  of  Processes 

Although  there  seems  to  be  little  agreement  on  what  a  process  is  or  the  main  elements  that  make 
it  up,  the  predominant  view  among  academics  and  practitioners  seems  to  be  that  a  process  is  a  set  of 
interrelated  activities  (Hunt,  1996;  Quid,  1995).  In  this  sense,  processes  are  seen  as  activity  flows 
(a.k.a.,  workflows)  composed  of  activities  that  bear  some  sort  of  relationship  with  each  other  (White 
and  Fischer,  1994).  This  means  that,  if  activities  are  not  perceived  as  interrelated,  they  are  not  part  of 
the  same  process. 

Among  activities  in  processes,  there  are  at  least  three  main  types  of  relationships,  which  we  refer 
to  as:  (a)  common  predecessor,  (b)  common  successor,  and  (c)  predecessor-successor.  These  rela¬ 
tionships  are  illustrated  in  Figure  1. 
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Figure  1.  “Receive  Materiais”  Process  of  a  Chimney  Manufacturer. 

Adapted  from  Kock  et  at.  (1997a,  p.  72). 

In  this  figure,  activities  are  shown  within  oval  shapes,  and  the  arrows  indicate  the  flow  of  execu¬ 
tion  of  the  activities  in  the  process.  Also,  a  rectangular  shape  represents  an  external  supplier  of  the 
process,  whereas  a  diamond  shape  indicates  a  decision  point  in  the  process.  Each  activity  is  described  by 
its  name  and  followed  (within  parentheses)  by  the  organizational  function  that  carries  out  the  activity 
and  the  italicized  name  of  the  main  tool  used  by  this  function.  Freestanding  text  that  begins  with  a 
“dash”  is  used  to  describe  a  “product,”  which  can  be  a  piece  of  data  or  a  material  thing  that  flows 
between  activities. 

The  common  predecessor  relationship  joins  together  activities  that  have  a  common  immediate 
predecessor  activity.  In  the  Figure  1  process,  this  relationship  is  shown  by  the  activities  order  a 
replacement  batch,  which  is  carried  out  by  the  acquisitions  assistant  (usually  by  fax),  and  send  a 
receipt  to  supplier,  which  is  also  carried  out  by  the  acquisitions  assistant,  who  typically  uses  ordinary 
mail.  Both  activities  have  the  same  immediate  predecessor  —  the  inspect  materials  activity  —  that  is 
done  by  the  quality  inspector,  who  uses  specialized  quality  inspection  equipment.  This  common 
predecessor  must  be  carried  out  before  each  of  these  two  interrelated  activities. 

The  common  successor  relationship  connects  activities  that  have  a  common  immediate  successor 
activity.  The  activities  stock  materials  and  update  stock  system  (the  former  done  by  the  stock  assistant 
with  the  use  of  a  forklift  and  the  latter  by  the  sales  assistant  on  a  computerized  stock  system)  are 
connected  through  a  common  successor  relationship.  Both  activities  have  a  common  successor  — 
the  activity  check  materials  in  stock  against  stock  system  —  which  is  performed  by  the  production 
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manager  by  walking  through  the  stock  warehouse  and  comparing  it  with  the  inventory  database  by 
using  a  laptop-based  version  of  a  computerized  stock  system. 

The  predecessor-successor  relationship,  the  most  common  type  of  relationship  between  activi¬ 
ties,  joins  together  two  activities  that  take  place  in  sequence,  one  after  the  other.  Note  that,  as  with  the 
two  types  of  relationships  described  above,  a  predecessor-successor  relationship  can  exist  even  if 
there  is  no  flow  of  data  or  materials  between  activities.  The  activities  receive  tubes  or  parts  and 
inform  quality  inspector  of  materials  arrival  are  connected  by  a  predecessor-successor  relaiiomhip 
as  they  can  only  be  carried  out  in  sequence,  the  second  after  the  first. 

The  process  of  creating  work-flow  representations  of  processes  is  typically  called  flowchart¬ 
ing.  According  to  Harrington  (1991,  p.  86),  this  process  is  “. . .  an  invaluable  tool  for  understanding 
the  inner  workings  of,  and  relationships  between,  business  processes.”  Irrespective  of  this  opinion, 
however,  work- flow  representations  of  processes,  such  as  those  in  Figure  1,  illustrate  an  important 
point  —  although  flowcharts  can  show  the  data  or  materials  that  flow  between  activities  in  a  process, 
these  data  or  materials  do  not  actually  flow  between  activities.  Hence,  the  data-flow  representation  in 
flowcharts  can  be  somewhat  misleading.  For  example,  the  delivery  form,  which  apparently  flows 
between  the  activities  inform  quality  inspector  of  materials  arrival  and  inspect  materials,  in  reality 
flows  between  the  organizational  functions  that  carry  out  these  activities  —  acquisitions  assistant  and 
quality  inspector.  The  delivery  form  is  a  data  repository  that  allows  for  the  exchange  of  information 
between  these  two  functions.  This  shortcoming  of  the  work-flow  view  can  be  of  significant  impor¬ 
tance  if  the  focus  of  a  process  redesign  attempt  is  on  the  flow  of  data,  not  the  activity  configuration  in 
a  process.  This  is  because  the  work-flow  view  “hides”  information  about  the  flow  of  data  in  organi¬ 
zational  processes  (Kock  and  McQueen,  1996). 

There  are  a  number  of  variations  of  work-flow  representations  similar  to  the  one  shown  in 
Figure  1 .  The  work  flow  in  Figure  1  itself  is  an  adaptation  of  the  ANSI  standard  flowchart,  and  it  has 
been  extensively  used  in  our  work  with  process  improvement  groups.  (See  Kock  (1995;  1999a)  for  a 
description  of  the  use  of  this  flowcharting  tool  in  process  improvement  groups.)  Flowchart  variations 
include  the  block  diagram,  functional  flowchart,  functional  timeline  flowchart,  and  geographic  flow¬ 
chart.  (See  Harrington  (1991)  for  a  more  detailed  discussion  of  these.) 

The  Data-flow  View  of  Processes 

Another  traditional  view  of  business  processes  is  through  data  flows,  where  processes  are  seen  as 
data  processing  entities.  Data-flow  representations  have  been  largely  used  in  the  1980s  by  systems 
analysts  as  an  important  component  of  what  are  known  as  structured  systems  analysis  and  design 
techniques  (Davis,  1983)  —  a  predecessor  of  the  object-oriented  analysis  and  design  approach 
(Somerville,  1992). 

Data-flow  representations  have  been  used  chiefly  to  understand  the  flow  of  data  within  processes 
and,  later,  to  automate  this  flow  “as  is”  rather  than  to  redesign  processes.  This  “automation-of-old- 
processes”  approach  has  been  the  target  of  strong  criticism  in  the  early  1990s  and  has  often  been 
described  as  the  main  cause  of  the  low  return  on  investment  in  information  technology  (IT)  observed 
in  both  the  1970s  and  1980s.  The  service  sector  has  been  particularly  affected  by  IT’s  low  return  on 
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investment,  which  has  steadily  declined  to  even  negative  figures;  and  IT  investment  has  led  to  a 
decrease  in  productivity  in  a  number  of  service  industries,  such  as  banking  and  insurance  (Hackett, 
1990). 

Like  the  work-flow  view  of  processes,  the  data-flow  view  can  be  expressed  through  a  family  of 
graphical  representations,  from  which  the  most  widely  used  is  the  data-flow  diagram  (DFD)  (Gore 
and  Stubbe,  1988;  Pressman,  1987).  An  example  of  a  DFD  obtained  from  the  analysis  of  the  flow  of 
data  between  the  restaurants  and  the  central  kitchen  of  an  Italian  restaurant  chain  is  shown  in  Figure 
2.  In  this  figure,  a  rectangular  shape  represents  a  data  source  or  destination  —  the  restaurant  manager 
and  the  central  kitchen  manager  functions.  Arrows  indicate  the  flow  of  data,  which  are  described  by 
freestanding  text  located  beside  the  arrows.  Oval  shapes  represent  activities.  Open-ended  rectangles 
represent  data  repositories. 

The  process  mapped  through  the  DFD  in  Figure  2  starts  with  a  chain  restaurant  manager,  who 
tells  the  manager  of  the  central  kitchen,  where  all  dish  items  are  prepared,  that  the  restaurant  is  short 
of  some  specific  items  (e.g.,  Bolognese  sauce,  spaghetti,  Italian  bread).  The  manager  of  the  central 
kitchen  then  fills  out  a  form,  specifying  what  items  are  out-of-stock  and  which  restaurant  needs  them. 
This  form  is  then  placed  in  the  assistant  manager’s  in-box.  Approximately  every  2  hours,  the  assistant 
manager  of  the  central  kitchen  goes  through  the  forms  in  the  in-box,  generates  the  orders  to  be  pre¬ 
pared  by  the  cooking  team,  and  stores  the  orders  in  the  out-box.  When  scheduling,  the  assistant 
manager  tries  to  optimize  the  work  of  the  cooking  team  by  grouping  requests  that  require  the  same 
resources  (e.g.,  ingredients,  cooking  equipment).  The  cooking  team  then  collects  the  orders  from  the 
assistant  manager’s  out-box  and  prepares  the  Italian  dish  items  ordered  on  a  first-come,  first-served 
basis.  They  also  pack  and  stock  these  items  in  the  delivery  room  as  soon  as  they  are  ready.  Delivery 


-out-of-stock  items 


-deliveries 
I  -delivery 


deliver  items  to 
restaurant 
(delivery  team) 


Figure  2.  “Fulfill  Order”  Process  of  a  Central  Kitchen  at  an  Italian  Restaurant  Chain. 

Adapted  from  Kock  (1995,  p.  44). 


forms  are  filled  out  and  attached  to  each  of  the  packaged  items  for  the  restaurants,  which  are  periodi¬ 
cally  delivered  by  the  central  kitchen’s  delivery  team. 

Although  an  incomplete  model  of  real  processes,  representations  based  on  the  data-flow  view  of 
processes,  such  as  DFDs,  show  the  flow  of  data  and  how  it  is  stored  in  a  relatively  clear  way.  As  such, 
one  can  reasonably  expect  these  representations,  in  some  cases,  to  be  more  appropriate  than  represen¬ 
tations  based  on  work  flow,  such  as  flowcharts.  This  is  true  especially  in  the  analysis  of  processes 
where  the  flow  of  data  is  particularly  intense. 

A  dramatic  increase  in  the  flow  of  data  has  been  predicted  as  one  of  the  characteristics  of  today’s 
and  the  near  future’s  economy,  particularly  in  the  developed  and  developing  countries  (Drucker, 
1989;  Toffler,  1970;  1991).  Hence,  it  is  reasonable  to  expect  that  representations  based  on  the  data¬ 
flow  view  of  processes  become  more  useful  in  process  improvement  attempts  than  representations 
based  on  the  work-flow  view.  As  mentioned  before  in  this  chapter,  the  latter  type  of  representations 
tend  to  provide  a  poorer  picture  of  the  flow  of  data,  preventing  the  identification  of,  for  example,  data 
“buffers.”  Data  buffers  are  organizational  functions  (rectangular  shapes  in  DFDs)  that  perform  the 
job  of  transferring  data  among  other  organizational  functions.  In  a  given  process,  these  “buffers”  are, 
therefore,  strong  candidates  to  be  removed  from  the  process  and  replaced  by  information  technology 
applications.  This  is  the  case  in  Figure  2,  where  the  function  central  kitchen  manager  acts  as  a  buffer 
between  the  restaurant  manager  and  the  assistant  manager  of  the  central  kitchen.  In  the  process  ana¬ 
lyzed,  the  manager  of  the  central  kitchen  receives  data  from  the  restaurant  manager  and  stores  it  in  a 
data  repository  that  will  be  used  as  input  by  the  assistant  manager  of  the  central  kitchen  to  generate  an 
order.  A  more  efficient  version  of  the  process  would  have  the  restaurant  manager  storing  this  data 
with  no  mediation  of  the  manager  of  the  central  kitchen,  who  could  use  that  time  to  do  other  things. 

How  much  detail  should  be  in  the  diagram  when  mapping  processes  through  either  flowcharts  or 
DFDs?  The  activities  in  a  process  representation  can  be  seen  as  subprocesses  themselves,  which  can, 
in  turn,  be  broken  into  new  activities.  In  fact,  seeing  the  activities  of  processes  as  lower-level  pro¬ 
cesses  and  generating  more-detailed  diagrams  by  “exploding”  these  lower- level  processes  is  a  com¬ 
mon  practice  in  both  flowcharting  and  DFD  generation  (Davis,  1983;  Maull  et  ah,  1995;  Pressman, 
1987).  In  doing  so,  however,  two  simple  guidelines  are  suggested  (Kock  and  McQueen,  1996): 

•  Each  graphical  representation  of  a  process  should  not  have  more  than  14  activity  symbols. 

•  In  a  process  improvement  context,  the  breadth  of  improvement  sought  should  define  the  level 
of  detail  when  modeling  processes. 

The  first  guideline  is  based  on  studies  about  general  human  cognitive  limitations  relating  graphi¬ 
cal  representations  and  diagrams  used  in  systems  analysis  and  design  (Kock,  1995a).  The  second 
guideline  is  based  on  a  relatively  new  concept  —  the  breadth  of  process  improvement  (Hall  et  ah, 
1993).  Roughly  speaking,  the  breadth  of  improvement  correlates  the  number  of  different  departments 
or  distinct  areas  affected  by  process  improvement  decisions.  The  larger  the  breath  of  improvement, 
the  less  process  detail  is  necessary.  If  one  wishes  to  improve  processes  that  cut  across  several  (perhaps 
all)  of  the  departments  of  an  organization,  the  process  representation  should  comprise  little  detail 
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about  subprocesses  that  belong  to  individual  departments.  As  a  general  rule  of  thumb,  the  total  num¬ 
ber  of  high-level  processes  used  to  effectively  represent  any  organizational  unit  can  be  anywhere 
between  10  and  20  (Hammer  and  Champy,  1993;  Maull  et  ah,  1995). 

Other  Process  Views 

Although  the  two  previously  discussed  process  views  —  the  work-flow  views  and  the  data¬ 
flow  views  —  are  the  most  relevant  ones  for  the  purposes  of  this  project,  there  are  other  views  of 
processes.  Among  these  are  the  systems  view  and  the  object-oriented  view,  briefly  discussed  below. 

The  Systems  View 

The  systems  view  of  processes  is  based  on  the  traditional  concept  of  system  —  an  assembly  of 
parts  that  cannot  be  understood  just  in  terms  of  its  components.  A  system  can  be  defined  by  its 
emergent  properties,  which  are  system  properties  and,  therefore,  meaningless  in  terms  of  the  parts  that 
make  up  the  system.  This  concept  is  illustrated  in  the  following  excerpt  by  Checkland  and  Scholes 
(1990,  p.  19): 

The  vehicular  potential  of  a  bicycle  is  an  emergent  property  of  the  combined  parts  of 
a  bicycle  when  they  are  assembled  in  a  particular  way  to  make  the  structured  whole. 

According  to  the  systems  view,  a  process  can  be  operationally  defined  as  an  abstract  entity  that 
represents  the  transformation  of  inputs  into  outputs  (Childe  et  ah,  1994;  Childe,  1995;  Kock,  1995a). 
In  a  process,  suppliers  provide  inputs,  and  customers  consume  outputs.  The  transformation  of  inputs 
into  outputs  is  aimed  at  adding  value  to  the  customers  of  the  process.  The  inputs  and  outputs  of  a 
process  may  be  of  three  different  types  —  goods,  services,  and  data  (Juran,  1989;  Kock  and  Tomelin, 
1996). 

While  philosophically  appealing,  the  main  problem  with  the  systems  view  of  processes  is  that  it 
adds  little  to  our  understanding  of  the  inner  workings  of  a  process  and,  therefore,  may  be  of  little  use 
to  those  who  try  to  change  the  process.  In  the  system  view,  processes  are  defined  by  means  of  sets  of 
emergent  properties  that  characterize  them;  the  relationship  between  their  components  is  of  second¬ 
ary  importance.^ 

In  spite  of  its  limitations,  the  systems  view  has  proven  to  be  more  useful  than  the  work-flow  view 
in  the  analysis  of  very  complex  (and  often  “messy”)  processes,  such  as  those  related  to  strategic 
decision  making.  These  processes  typically  cannothe  analyzed  as  work  flows  because,  among  other 
things,  the  number  of  activities  and  decision  points  required  to  represent  them  is  too  large  to  allow  for 
effective  modeling. 


'  We  are  referring  mainly  to  the  British  systems  perspective  here,  which  has  been  highly  influenced  by  Peter 
Checkland  and  colleagues.  Another  systems  view  of  processes  that  is  popular  in  American  research  circles,  particularly 
in  the  field  of  operations  research,  focuses  on  managing  and  coordinating  complex  interactions,  e.g.,  global  warming. 
This  other  systems  view  later  evolved  into  the  so-called  “chaos  theory.” 
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The  Object-oriented  View 


One  of  the  main  proponents  of  the  object-oriented  view  of  processes  is  Ivor  Jacobson,  who  devel¬ 
oped  a  methodology  to  model  processes  as  data  objects.  Jacobson’s  methodology  was  based  on  the 
concept  of  the  software  object  (Jacobson  et  ah,  1995).  A  software  object  is  a  data  repository  with  a 
number  of  associated  operations.  These  operations  are  also  called  methods  in  the  technical  jargon  of 
object-oriented  analysis  and  programming  (Thomas,  1989).  A  software  object  typically  stores  data  in 
its  attributes,  which  are  analogous  to  the  attributes  of  real  objects  like  a  chair  (e.g.,  the  attributes  of  an 
object  chair  are  its  color,  weight,  and  number  of  legs)  (Partridge,  1994). 

The  object-oriented  view  can  be  seen  as  an  extension  of  the  data-flow  view  in  which  data 
repositories,  represented  in  DFDs  by  open-ended  rectangles  (see  Figure  2),  are  permanently  linked 
to  activities  that  change  the  content  of  those  repositories.  There  is  a  clear  advantage  in  adopting  this 
view.  Many  believe  that  object-oriented  programming  is  increasingly  becoming  the  dominant  soft¬ 
ware  development  paradigm  (i.e.,  it  has  been  adopted  by  most  of  the  major  players  who  were 
active  in  the  software  development  industry  during  the  1990s).  Also,  the  object-oriented  view  of 
processes  allows  for  an  inexpensive  transition  between:  (a)  process  analysis  and  redesign,  and  (b) 
the  development  of  new  computer  systems  to  support  the  implementation  of  the  new  redesigned 
processes. 

However,  the  object-oriented  view  has  been  criticized  for  its  excessively  technical  orientation, 
which  prevents  less  sophisticated  users  (i.e.,  those  who  are  unfamiliar  with  object-oriented  concepts) 
from  effectively  understanding  it  in  its  full  complexity  and  adopting  it  in  process  improvement  projects. 
Process  analysis  and  design  methodologies  using  object-oriented  representations,  such  as  the  Unified 
Modeling  Language  (UML),  are  still  too  complex  to  be  widely  accepted  and  used  in  organizations  in 
spite  of  the  fact  that  UML  has  been  endorsed  by  several  “heavyweights”  in  the  computer  community 
(Meyer,  1998).  This  has  been  compounded  by  the  fact  that,  among  less  sophisticated  users,  there  are 
often  senior  managers  who  are  usually  absorbed  in  strategic  management  issues  and,  therefore,  do 
not  have  the  time  to  become  technically  sophisticated.  The  problem  with  this  situation  is  that  the 
support  of  such  managers  is  a  fundamental  ingredient  in  successful  process  improvement  initiatives 
(Davenport,  1993). 

Moreover,  some  recent  software  industry  developments  have  turned  the  building  of  customized 
computer  systems  (often  “in-house”),  which  is  facilitated  by  the  adoption  of  the  object-oriented  view 
of  processes,  into  an  often  undesirable  and  expensive  alternative.  Buying  and  customizing  of-the- 
shelf  applications  and  enterprise  resource  planning  systems  as  well  as  outsourcing  data  and  applica¬ 
tion  management  to  enable  new  organizational  processes  are  seen  by  many  as  more  desirable  ap¬ 
proaches  made  possible  by  such  developments. 

Data,  Information  and  Knowledge:  Different  Words  for  the  Same  Concept? 

We  hear  the  words  “data,”  “information,”  and  “knowledge”  quite  often  being  used  as  if  they  were 
synonymous;  but  are  they  actually  the  same  thing?  If  not,  what  are  the  differences? 
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The  contribution  of  IT  providers  has  perhaps  been  unmatched  in  its  potential  to  add  to  our 
confusion  over  the  distinction  between  data  and  information.  Examples  can  be  found  in  almost  any 
specialized  IT  publication,  conversations  with  IT  company  representatives,  and  even  in  public 
speeches  by  IT  “gurus.”  For  example,  a  senior  vice-president  of  a  large  software  development 
company  was  one  of  the  keynote  speakers  of  a  recent  information  systems  conference.  He  referred 
to  the  advantages  of  a  well-known  commercial  group  support  system  in  the  following  terms: 

“. . .  information  overflow  can  be  considerably  reduced  ...  for  example,  a  few  weeks 
ago  I  prepared  a  2  megabyte  report  and  sent  it  via  electronic  mail  to  ten  people.  Each 
of  these  ten  people  forwarded  a  copy  of  the  report  to  about  ten  other  people  ...  as  a 
result,  my  report  had  generated  a  flow  of  200  megabytes  of  information  in  the  net¬ 
work,  in  less  than  four  days  ...” 

In  the  example  above,  the  speaker  was  referring  to  data,  which  can  be  measured  in  megabytes,  as 
synonymous  with  information.  This  can  often  be  misleading  because  large  sets  of  data  may  have  very 
low  information  content,  depending  on  how  well  the  data  receiver  is  prepared  to  make  sense  of  it. 
Mistakenly  identifying  data  as  information  is  as  commonplace  as  confusing  knowledge  with  informa¬ 
tion. 

It  is  curious  that  the  confusion  over  what  information  and  knowledge  are  has  been  nurtured  by 
some  of  those  people  who  are  widely  recognized  as  among  the  forerunners  of  the  study  of  informa¬ 
tion  and  knowledge  and  their  impact  on  organizations  and  society.  For  example,  one  of  the  most 
highly  regarded  management  consultants  and  researchers,  Peter  Drucker  (1989,  pp.  207-208),  de¬ 
scribes  the  emergence  of  the  information-based  organization  in  the  following  terms: 

...  the  business,  and  increasingly  the  government  agency  as  well,  will  be  knowl- 
edge-hased,  composed  largely  of  specialists  who  direct  and  discipline  their  own 
performance  through  organized  feedback  from  colleagues  and  customers.  It  will  be 
an  information-based  organization  . . .  Today’s  typical  organization,  in  which  knowl¬ 
edge  tends  to  be  concentrated  in  service  staffs  perched  rather  insecurely  between  top 
management  and  the  operating  people,  will  likely  be  labeled  a  phase,  an  attempt  to 
infuse  knowledge  from  the  top  rather  than  obtain  information  from  below  [our  em¬ 
phasis]. 

If  information  and  knowledge  were  the  same  thing,  why  use  two  words  when  just  one  would 
suffice?  Even  though  information  and  knowledge  mean  different  things  to  different  people,  most 
people  use  them  in  different  senses.  The  main  reason  these  two  words  are  often  used  interchangeably 
is  exactly  because  there  is  no  agreement  over  their  meaning. 

But,  why  should  we  worry  about  the  different  nature  of  data,  information,  and  knowledge?  One 
reason  is  because  an  ocean  of  data  may  contain  only  a  small  amount  of  information  that  is  of  any 
value  to  us,  and  sifting  through  this  ocean  of  data  may  be  severely  time-consuming  (Goldratt,  1991). 
But  there  are  other  reasons,  and  they  relate  to  our  understanding  of  the  world. 


12 


The  world  is  not  only  what  we  perceive  it  to  be  through  our  senses;  it  is  a  combination  of  these 
perceptions  and  what  is  stored  in  our  body,  mostly  in  our  brain  in  the  form  of  neural  networks  (Callatay, 
1986;  Dozier,  1992).  We  can  develop  our  neural  networks  by  interacting  with  matter  and  living 
organisms,  notably  other  human  beings.  However,  in  order  to  interact  with  other  human  beings,  we 
need  to  externalize  what  is  stored  in  our  neural  networks  by  means  of  a  code.  Other  human  beings 
must  understand  this  code  so  communication  takes  place. 

If  data  and  information  are  the  same,  how  can  the  content  of  one  E-mail  message  be  interpreted 
differently  by  various  recipients?  Let  us  suppose  that  an  E-mail  message,  written  in  Spanish  (a  spe¬ 
cific  code),  is  sent  to  two  different  recipients.  While  one  of  the  recipients  can  read  Spanish  very  well, 
the  other  cannot.  In  this  example,  the  message  takes  up  the  same  disk  space  (say,  3.6  kilobytes)  on  the 
computers  of  each  of  the  recipients,  which  is  a  measure  of  the  amount  of  data  related  to  the  message. 
Yet,  its  information  content  is  much  higher  for  the  recipient  who  can  read  Spanish  than  for  the  recipi¬ 
ent  who  cannot. 

If  data  and  information  are  the  same,  then  they  should  not  yield  different  “amounts”  when  mea¬ 
sured  for  the  same  object  (in  this  case,  the  E-mail  message  in  Spanish).  It  is  important  to  stress  that 
different  terms  could  have  been  used  in  this  discussion;  for  example,  instead  of  “data”  and  “informa¬ 
tion,”  “alpha-stractum”  and  “capta”  could  be  used.  The  more  commonly  used  terms  data  and  infor¬ 
mation  are  used  in  this  report  because  we  believe  that  the  sense  in  which  we  have  just  used  these  two 
terms  is  their  most  “usual”  sense. 

The  distinction  between  knowledge  and  information  is  a  bit  more  abstract  than  the  distinction 
between  information  and  data.  In  order  to  make  this  distinction  as  clear  as  possible,  consider  the 
following  dialogue  between  a  doctor  (D)  and  her  patient  (P): 


D:  So,  what  brings  you  here  today  ? 

P:  I  don ’t  know  doctor,  I’ve  been  feeling  a  bit  strange  in  the  last  couple  of  weeks. 

D:  What  do  you  mean  by  “strange  ”  ? 

P:  Burning  eyes,  stuffy  nose  . . .  and  these  things  go  and  come  several  times  a  day. 

D:  Any  headaches  or  fever? 

P:  No,  not  at  all. 

D:  Well,  we  ’ll  run  a  checkup  on  you,  but  I  think  you  probably  have  an  allergy. 

The  patient  was  feeling  the  symptoms  of  what  could  be  an  allergy  and,  therefore,  went  to  see  the 
doctor,  an  expert  who  likely  knows  more  about  medicine  than  the  patient.  The  patient  described  the 
symptoms,  and  the  doctor  made  the  tentative  diagnosis,  “. . .  you  probably  have  an  allergy.”  Is  what 
the  patient  told  the  doctor  enough  for  anyone  without  any  medical  expertise  to  come  up  with  the  same 
tentative  diagnosis?  Well,  if  this  were  the  case,  very  few  people  would  agree  to  pay  doctors  for 
consultations.  Doctors  possess  more  of  something  the  patients  do  not  have,  something  typically  re¬ 
ferred  to  as  knowledge,  in  the  specific  field  of  medicine. 


13 


Is  the  nature  of  the  expert  knowledge  possessed  (by  the  doctor,  in  this  case)  the  same  as  that  of  the 
perception  of  symptoms  experienced  by  the  patient?  No,  for  the  simple  reason  that  expert  knowledge 
can  be  used  to  generate  conclusions  based  on  the  description  of  symptoms.  This  is  something  that  the 
descriptions  alone  cannot  do.  Therefore,  the  natures  of  descriptions  and  expert  knowledge  are  differ¬ 
ent,  and  it  can  be  shown  that  neither  of  them  is  the  same  as  the  nature  of  data.  This  also  suggests  that 
descriptions  are  instances  of  something  unique  —  referred  to  here  as  information. 

Data  are  Carriers 

In  the  usual  sense  of  the  term,  data  are  considered  carriers  of  information  and  knowledge.  The 
flow  of  data  in  organizational  processes  among  the  functions  that  carry  out  process  activities  takes 
place  through  various  media,  particularly,  paper,  digital  electrical  impulses  (e.g.,  electronic  data  inter¬ 
change  systems),  analog  electrical  waves  (e.g.,  telephone),  electromagnetic  waves  (e.g.,  radio),  and 
air  vibrations  (e.g.,  face-to-face  conversation).  Data  can  also  be  stored  for  later  use  on  different  stor¬ 
age  media,  such  as  magnetic  media  (e.g.,  hard  and  floppy  disks),  paper,  and  volatile  digital  memories 
(e.g.,  RAM  memory  in  personal  computers). 

Data  are  either  transferred  or  stored  through  a  process  of  “changing”  or  generating  perturba¬ 
tions  on  a  given  medium.  A  blank  sheet  of  paper,  for  example,  can  be  used  for  data  storage  (e.g., 
to  write  down  an  address  of  a  friend)  or  transfer  (e.g.,  to  write  a  memo  to  an  employee  by 
applying  ink  to  paper).  Or,  from  a  more  business-oriented  perspective,  if  a  machine  operator 
wants  to  tell  his  supervisor  about  a  problem  with  a  metal-shaping  machine,  the  operator  can 
approach  the  supervisor  and  speak  face-to-face.  In  doing  so,  the  operator  uses  vocal  cords  to 
generate  vibrations  in  the  air  (volatile  data)  that  will  be  received  and  decoded  by  the  recipient 
through  hearing  organs. 

Data  will  only  become  information  or  knowledge  when  it  is  interpreted  by  human  beings  (Kryt, 
1997)  or,  in  some  cases,  by  artificial  intelligence.  (See  Russel  and  Norvig,  1995,  for  an  example.)  As 
data  can  be  stored  and  transferred  by  process  functions  through  applying  changes  to  storage  and 
communication  media  that  will  be  interpreted  by  other  process  functions,  an  operational  definition 
within  the  context  of  process  management  might  be  as  follows: 

If  John  performs  an  organizational  function,  such  as  carrying  out  an  activity  in  an 
organizational  process,  then  the  data  are  permanent  or  volatile  changes  applied  to  a 
communication  medium  by  John  to  store  or  transfer  information  or  knowledge.  These 
will  later  be  used  by  John  or  someone  else  (or  an  artificial  intelligence  agent)  to  per¬ 
form  an  organizational  activity. 

The  measurement  of  data  depends  on  the  medium  used  to  store  or  transfer  it  as  well  as  on  the  code 
used.  In  most  organizational  processes,  data  can  be  measured  in  words  or  symbols,  when  the  medium 
used  is  paper,  and  in  bits  or  bytes  ( 1  byte  is  a  group  of  8  bits),  when  the  medium  used  is  a  digital  one. 

In  many  ways,  a  bit  can  be  considered  the  smallest  and  most  fundamental  unit  of  data.  It  can  take 
only  two  values:  0  (or  false)  and  1  (or  true).  A  group  of  8  bits  forms  a  byte;  and,  since  the  number  of 
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possible  bytes  is  2^  or  256,  there  can  be  a  direct  correspondence  between  bytes  and  certain  symbols 
(e.g.,  the  letters  of  the  English  alphabet  and  other  alphabets).  One  such  set  of  symbols,  which  is 
largely  used  to  convert  alphanumeric  characters  into  bytes  and  vice-versa,  is  called  the  ASCII  code 
(American  Standard  Code  for  Information  Exchange).  Most  computer  operating  systems  use  the 
ASCII  code,  or  an  extended  version  of  it,  to  map  symbols  that  have  meaning  to  human  beings  (e.g., 
letters  and  numbers)  into  bytes  stored  in  any  of  the  computers’  data  storage  devices  (e.g.,  RAM,  hard 
disk,  etc.). 

Information  is  Descriptive 

A  hot  issue  in  business  circles  in  the  1990s  has  been  the  advent  of  the  “information  society,”  the 
“information  era,”  and  the  “information-intensive”  organizations.  However,  any  discussion  regarding 
these  issues  should,  of  necessity,  focus  on  the  nature  of  information.  What  is  it?  Is  it  a  specific  kind  of 
entity?  If  yes,  how  can  we  differentiate  information  from  other  similar  entities?  These  are  core  ques¬ 
tions  in  the  continuing  debate  within  a  number  of  disciplines,  such  as  information  systems,  manage¬ 
ment  science,  engineering,  and  philosophy.  A  substantial  portion  of  the  literature  in  these  disciplines 
is  devoted  to  defining  information,  however,  as  Budd  and  Raber  (1996,  p.  217)  note  in  the  following: 

In  the  course  of  doing  so  [i.e.  defining  information],  many  aspects  of  information 
(technical,  physical,  semantic,  epistemological)  are  featured  as  part  of  the  discussion. 

Part  of  what  emerges  is  a  multifaceted  idea  and  thing  that  is,  at  times,  defined  in  terms 
of  what  it  is  not.  Eor  instance,  information  is  not  merely  data;  organization  and  in¬ 
tended  meaning  transform  the  bits  of  data  into  something  that  can  inform. 

Erom  a  process-oriented  view,  information  can  be  seen  as  carried  by  data  and  as  being  eminently 
descriptive.  Erom  a  linguistic  perspective,  the  typical  instance  of  information  is  the  utterance  called 
assertion.  One  example  of  assertion  is:  “Today  is  a  sunny  day.”  Independently  of  what  this  assertion 
means  exactly  (the  word  “sunny”  can  mean  different  things  to  different  people,  from  sparsely  clouded 
to  clear-sky  weather),  it  provides  a  description  of  the  current  state  of  the  environment  surrounding  us. 
If  the  environment  is  seen  as  an  object,  the  assertion  can  be  seen  as  defining  an  attribute  of  the 
object,  in  this  case,  the  weather  as  sunny. 

Information  can  be  qualified  in  different  ways.  It  can  be  more  or  less  complete  or  accurate;  and  it 
can  refer  to  the  past,  present,  and  future.  Eor  example,  the  assertion,  “Today  is  hot!”  conveys  less 
accurate  information  than  the  assertion,  “Today’s  average  temperature  is  85  degrees  Eahrenheit.” 
Both  assertions  describe  the  present,  that  is,  today.  The  assertion,  “The  temperature  on  this  day  during 
the  last  3  years  has  averaged  87  degrees  Eahrenheit,”  provides  information  about  the  past.  The  asser¬ 
tion,  “Tomorrow  the  top  temperatures  will  be  in  the  low  90s,”  provides  a  description  of  the  future. 
Although  similar  to  descriptions  of  the  past  and  the  present,  descriptions  of  the  future,  by  their  own 
nature,  always  carry  a  certain  degree  of  uncertainty. 

Knowledge,  which  will  be  discussed  in  more  detail  in  the  next  section,  is  often  used  to  generate 
more  information  based  on  information  at  hand.  The  information  thereby  generated  (or  inferred)  is 
usually  not  obvious  and,  therefore,  possesses  some  added  value  in  relation  to  the  primary  information 
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received  as  an  input  by  the  knowledge  holder.  One  example  is  the  generation  of  information  about  the 
future  (e.g.,  the  weather  in  New  York  tomorrow)  based  on  information  about  the  present  and  past 
(e.g.,  the  weather  patterns  in  New  York  during  the  last  2  years)  up  to  now.  This  type  of  information 
about  the  future  is  produced  by  meteorologists,  based  on  their  knowledge  about  the  science  of  weather 
forecasting.  It  is  then  purchased  by  news  services  that,  in  turn,  broadcast  the  information  to  their 
audiences  and,  in  the  process  of  doing  so,  manage  to  make  a  profit. 

The  Value  of  Information 

One  interesting  aspect  of  information  is  that  it  has  value  —  how  much  someone  is  willing  to  pay 
for  it  and  can  benefit  from  it.  In  general,  this  seems  to  directly  correlate  some  of  its  attributes.  Among 
these  attributes,  it  has: 

•  Advanceness,  that  is,  how  much  time  in  advance  it  describes  the  future  (if  it  refers  to  the  future 
rather  than  to  the  past  or  present); 

•  Accuracy,  that  is,  how  accurate  the  description  is;  and 

•  Completeness,  that  is,  how  complete  the  description  is. 

Let  us  explain  the  different  nature  of  the  attributes  above  in  a  business  context.  The  “corporate 
war”  between  Coca-Cola  and  Pepsi  in  the  1980s  was  largely  one  of  product  differentiation  (Ramsey, 
1987).  Both  Coca-Cola  and  Pepsi  tried  to  increase  their  shares  of  the  “cola”  soft  drink  market  by 
launching  new  differentiated  (e.g.,  diet)  products  ahead  of  each  other.  Consider  the  similar  situation 
of  two  companies,  A  and  B,  competing  for  2  million  customers  in  the  same  industry.  Each  customer 
consumes  a  product  supplied  by  both  companies.  Analogous  to  the  “cola”  war,  the  product  is  essen¬ 
tially  the  same,  the  main  difference  being  the  brand.  Each  customer  consumes  70  units  of  the  product, 
which  costs  $3  each,  every  year;  this  makes  it  a  $420  million  per  year  market.  Company  A  has  90 
percent  of  the  market  or  $378  million,  while  Company  B  has  the  other  10  percent  or  $42  million. 
Both  companies  sell  with  a  pretax  profit  margin  of  17  percent,  which  yields  approximately  $64 
million  for  Company  A  and  $7  million  for  Company  B  in  absolute  pretax  profits. 

Now,  suppose  Company  B  decides  to  launch  a  new  product  into  the  market,  whose  development 
time  is  approximately  9  months.  The  product  has  the  potential  to  bring  Company  B’s  market  share  up 
to  20  percent,  and  send  Company  As  share  down  to  80  percent.  This  would  raise  Company  B’s 
pretax  profits  up  to  about  $14  million  and  make  Company  A’s  profits  plummet  to  nearly  $57  million. 
Erom  Company  A’s  perspective  (the  value  of  information  always  depends  on  its  user  and  the  context), 
one  piece  of  information  —  the  information  that  Company  B  is  going  to  launch  a  new  product  —  can 
make  a  big  difference.  This  piece  of  information  can  have  a  high  advanceness  if  it  is  provided  to 
Company  A  well  in  advance  of  the  product  launch,  which  would  enable  Company  A  to  take  appro¬ 
priate  countermeasures.  The  same  piece  of  information  can  have  a  high  accuracy,  providing  accurate 
details  about  the  product  that  is  going  to  be  launched  (e.g.,  it  might  include  the  precise  date  of  launch). 
The  information  can  also  have  high  completeness  by  providing  a  rich  description  of  the  new  aspects 
of  the  product  (i.e.,  the  new  flavor,  amount  of  saturated  fat,  sweetener  used,  etc.). 
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If  Company  A  has  no  access  to  information  about  the  new  product  launch  and  obtains  some 
imprecise  information  a  few  weeks  before  the  new  product  is  launched,  it  will  have  to  endure  a  loss 
in  pretax  profits  of  $7  million  —  the  worst-case  scenario.  However,  if  it  gets  accurate  and  complete 
information  early  enough,  it  can  take  preventive  measures  whereby  it  can  at  least  reduce  its  losses. 
For  example,  if  the  information  is  obtained  more  than  9  months  in  advance  (i.e.,  has  high  advanceness) 
but  leaves  uncertainty  about  the  characteristics  of  the  product  (i.e.,  has  low  accuracy  and  complete¬ 
ness),  Company  A  might  have  to  develop  a  range  of  new  products  to  dampen  the  potential  impact  of 
Company  B’s  new  product  on  the  market  share.  Its  profits  may  still  be  reduced  due  to  increased 
product  development  costs . 

Having  access  to  detailed  information  about  Company  B’s  new  product  (i.e.,  highly  accurate  and 
complete  information)  only  4  months  before  the  launch  (i.e.,  low  advanceness  information)  may  lead 
to  a  similar  end  result;  that  is.  Company  A  may  be  able  to  develop  an  intermediary  product  that  will 
reduce  the  impact  of  Company  B’s  new  product  on  market  share. 

Perhaps  the  best  scenario  is  that,  if  Company  A  has  access  to  highly  detailed  information  (i.e., 
highly  accurate  and  complete  information)  about  Company  B’s  new  launch  early  enough  (i.e.,  the 
information  has  high  advanceness),  it  can  develop  a  similar  new  product  and  get  it  out  into  the  market 
before  Company  B.  According  to  our  initial  assumptions,  this  could  potentially  bring  Company  A’s 
market  share  up  to  95  percent  and  increase  profits  by  about  $4  million. 

In  the  example  above,  no  information  or  information  with  low  accuracy,  completeness,  or 
advanceness,  would  be  of  low  value  to  Company  A.  Information  with  high  accuracy  and  complete¬ 
ness,  but  low  advanceness  (or  vice  versa)  would  have  a  medium  value  as  it  could  prevent  a  loss  of  $7 
million  in  pretax  profits  a  year.  Finally,  information  with  high  accuracy,  completeness,  and  advanceness 
would  have  a  high  value,  enabling  an  increase  in  profits  of  $4  million  a  year.  This  relationship  be¬ 
tween  information  value  and  its  attributes  is  illustrated  in  Figure  3. 

Although  the  example  above  is  concerned  with  a  decision-making  process  at  the  strategic  level, 
the  relationship  between  information  value  and  the  attributes  advanceness  and  accuracy  can  be  ex¬ 
trapolated  from  most  organizational  processes.  Simply  put,  process-related  information  seems  to  be 
an  important  enabling  factor  for  the  members  of  a  process  team  (i.e.,  those  who  perform  process 
activities)  to  do  their  job  efficiently  and  effectively,  whatever  the  process  is. 
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Figure  3.  The  Value  of  Information. 
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Knowledge  is  Associative 

While  information  is  eminently  descriptive  and  can  refer  to  the  past,  present,  and  future,  knowl¬ 
edge  is  highly  associative.  That  is,  knowledge  allows  us  to  “associate”  different  world  states  and 
respective  mental  representations.  These  representations  are  typically  linked  to,  or  described  by,  pieces 
of  information  (i.e.,  knowledge  allows  us  to  link  different  pieces  of  information  and  make  decisions 
based  on  associations).  The  associative  aspect  of  knowledge  can  be  divided  into  two  types,  namely 
correlational  and  causal,  which  are,  in  turn,  only  two  types  of  what  is  referred  to  by  Weick  and 
Bougon  (1986,  p.  104)  as  “cognitive  archetypes.” 

Correlational  knowledge  usually  connects  two  or  more  pieces  of  information  that  describe  events 
or  situations  that  have  happened,  are  happening,  or  will  happen  at  the  same  time.  Causal  knowledge 
connects  pieces  of  information  that  describe  the  state  of  the  world  at  different  times.  For  example, 
consider  the  associative  knowledge  represented  in  the  following  decision  rule:  “If  John  has  a  fever  and 
is  sneezing,  then  John  is  likely  to  have  a  cold.”  The  knowledge  embodied  in  this  decision  rule  is  of  the 
correlational  type  because  it  affirms  that  someone  who  has  a  fever  and  sneezing  is,  in  fact,  displaying 
typical  cold  symptoms  (i.e.,  “fever,”  “sneezing,”  and  “cold”)  typically  happen  at  the  same  time. 

Another  example  of  a  different  type  of  knowledge  is  provided  by  the  rule,  “If  John  smokes  a  lot, 
then  he  will  probably  die  from  lung  cancer.”  This  decision  rule  expresses  causal  knowledge.  As  such, 
the  rule  connects  two  events  that  take  place  at  different  times  —  John  smokes  a  lot  in  the  present,  and 
John  may  dye  of  lung  cancer  in  the  future.  Dennett  (1991,  p.  144)  refers  to  causal  knowledge  when 
he  claims  that: 

The  brain’s  task  is  to  guide  the  body  it  controls  through  a  world  of  shifting  conditions 
and  sudden  surprises,  so  it  must  gather  information  from  that  world  and  use  [it]  swiftly 
to  “produce  future”  —  to  extract  anticipations  in  order  to  stay  one  step  ahead  of  disas¬ 
ter  [original  emphasis]. 

Knowledge  drives  the  flow  of  myriad  decisions  that  have  to  be  made  even  in  the  simplest  organi¬ 
zational  processes.  Steel  plants,  for  example,  rely  on  process  teams  to  load  and  operate  smelters. 
Consider  the  predictive  knowledge  expressed  in  the  rule,  “If  the  smelter  is  set  at  a  temperature  of 
3,000  degrees  Celsius,  then  a  1-ton  load  of  steel  will  be  smelted  in  43  minutes.”  This  is  one  of  the 
pieces  of  knowledge  that  allows  a  smelter  operator  to  predict  that  a  batch  of  solid  steel  weighing 
about  1  ton  will  be  in  liquid  form  approximately  43  minutes  after  it  is  loaded  into  the  smelter,  if  the 
smelter  is  set  properly.  This  prediction  allows  the  smelter  operator  to  program  a  stop  in  the  smelting 
process  at  the  right  time  and  let  the  liquid  steel  flow  out  of  the  smelter,  which  saves  energy  and,  at  the 
same  time,  prevents  the  steel  from  overcooking. 

For  teamwork  to  yield  effective  and  efficient  outcomes,  those  who  perform  activities  in  a  process 
must  share  predictive  knowledge.  In  the  example,  those  who  use  the  steel  in  liquid  form  for  shaping 
steel  parts  should  ideally  hold  at  least  part  of  the  knowledge  held  by  the  smelter  operator.  If  they  know 
of  the  “43  minute  rule,”  they  can  also  predict  that  a  batch  of  steel  will  be  ready  43  minutes  from  the 
time  it  is  loaded  in  solid  form  and  have  their  own  equipment  prepared  at  the  right  time  to  work  on  the 
liquid  steel. 
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In  general,  business  knowledge  is  inextricably  linked  with  decision  making  (Olson  and 
Courtney,  1992;  Holsapple  and  Whinston,  1996),  perhaps  because  one  of  the  best  ways  of  as¬ 
sessing  the  actual  value  of  knowledge  is  through  the  assessment  of  the  outcomes  of  decisions 
made  based  on  it.  Holsapple  and  Whinston  (1996,  p.  6)  talk  of  the  importance  of  knowledge  for 
decision  making: 

For  centuries,  managers  have  used  the  knowledge  available  to  them  to  make  decisions 
[original  emphasis]  shaping  the  world  in  which  they  lived.  The  impacts  of  managers’ 
decisions  have  ranged  from  those  affecting  the  world  in  some  small  or  fleeting  way  to 
those  of  global  and  lasting  proportions.  Over  the  centuries,  the  number  of  decisions 
being  made  per  time  period  has  tended  to  increase.  The  complexity  of  decision  activi¬ 
ties  has  grown.  The  amount  of  knowledge  used  in  making  decisions  has  exploded. 

There  is  no  sign  that  these  trends  are  about  to  stop.  If  anything,  they  appear  to  be 
accelerating. 

Knowledge  has  been  distinguished  from  information.  It  is  also  linked  with  decision  making  in 
different  fields  of  research  and  academic  disciplines.  In  the  field  of  artificial  intelligence,  for  example, 
information  has  been  typically  represented  through  “facts.”  Knowledge,  on  the  other  hand,  has  been 
expressed  by  means  of  a  number  of  different  representations,  such  as  semantic  networks,  frames, 
scripts,  neural  networks,  and  production  rules;  the  latter  is  the  most  common  in  practical  knowledge- 
based  computer  systems  (Callatay,  1986;  Holyoak,  1991;  Olson  and  Courtney,  1992).  Production 
rules  are  conditional  statements  in  if-then  form,  like  the  ones  used  to  exemplify  knowledge  in  this 
section. 

In  the  fields  of  psychology  and  social  cognition,  knowledge  has  been  expressed  through  schemas 
(Lord  and  Foti,  1986)  and  cognitive  maps  (Weick  and  Bougon,  1986).  These  are,  in  turn,  seen  as 
guiding  individual  and  group  behavior  and  using,  as  input,  environmental  stimuli  obtained  through 
the  senses.  The  concept  of  schema  was  developed  as  a  reaction  to  studies  of  memory  pioneered  by 
Ebbingaus,  who  made  use  of  arbitrary  materials  and  sensorial  stimuli  to  determine  factors  that  influ¬ 
ence  the  formation  of  memory  and  recall  of  information  (Gardner,  1985).  The  development  of  the 
concept  of  schema  is  credited  to  Bartlett  (1932),  who  used  an  Indian  folktale  called  “The  War  of  the 
Ghosts”  to  show  that  existing  mental  structures  strongly  influenced  memory  formation  and  recall. 
Such  existing  mental  structures,  which  were  used  by  Bartlett’s  study  subjects  to  process  information 
coming  from  the  tale,  were  called  schemas.  Essentially,  Bartlett  has  shown  that  individuals  possess¬ 
ing  different  schemas  would  interpret  the  tale,  which  is  filled  with  strange  gaps  and  bizarre  causal 
sequences,  in  substantially  different  ways. 

In  biology  (more  particularly  in  neurology)  knowledge  is  typically  associated  with  long-term, 
nerve-based  memory  structures  that  mainly  process  information  (Pinker,  1997).  Information  is  seen 
as  usually  associated  with  short-term  neural  connections  that  appear  to  “vanish”  from  conscious 
memory  after  a  while.  Eor  example,  the  knowledge  of  how  to  operate  a  telephone  is  stored  in  long¬ 
term  memory  structures,  whereas  the  information  represented  by  a  phone  number  is  stored  in  short¬ 
term  memory  structures. 
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The  Value  of  Knowledge 

Knowledge  is  usually  much  more  expensive  to  produce  than  information.  For  example,  informa¬ 
tion  in  the  form  of  mutual  fund  indicators  (e.g.,  weekly  earnings,  monthly  price  fluctuation,  etc.)  is 
produced  by  means  of  simple  calculations  performed  on  data  about  share  prices  and  their  fluctuation 
over  a  time  period.  The  knowledge  of  how  mutual  fund  indicators  fluctuate,  however,  requires  years 
of  analysis  of  information  built  up  over  time.  This  analysis  of  information  leads  to  the  development  of 
knowledge  that  allows  an  expert  investor  to  select  the  best  mutual  funds  according  to  the  configura¬ 
tion  of  the  economy.  This  leads  us  to  the  question:  How  is  knowledge  produced? 

Comparative  studies  of  experts  and  nonexperts  suggest  that  expertise  is  usually  acquired  through 
an  inductive  process  in  which  generalizations  are  made  based  on  the  frequency  with  which  a  certain 
piece  of  information  occurs.  These  generalizations  are  the  basis  for  the  construction  of  knowledge 
(Camerer  and  Johnson,  1991). 

A  different  and  less  common  method  used  to  generate  knowledge  is  deduction,  whereby  hidden 
knowledge  is  produced  based  on  existing  knowledge  taken  through  a  set  of  logical  steps  (Teichman  and 
Evans,  1995).  This  method  has  been  used  in  the  development  of  a  large  body  of  knowledge  in  the  form 
of  “theorems,”  particularly  in  the  fields  of  mathematics  and  theoretical  physics  (Hawking,  1988). 

An  example  of  knowledge-building  through  induction  is  that  undergone  by  novice  investors  in 
the  stock  market.  The  observation  that  shares  of  a  small  number  of  companies  in  high  technology 
industries  have  risenlO  percentage  points  above  the  Standard  &  Poor’s  500  Average  Index  during  a 
period  of  6  months  may  prompt  novice  investors  to  put  all  of  their  money  into  these  shares.  However, 
a  professional  investor  withlO  years  experience  as  a  broker  in  the  stock  market  knows  that  a  6-month 
observation  period  is  not  long  enough  to  support  such  a  risky  decision  and  opts  for  a  more  diversified 
portfolio.  In  cases  such  as  these,  a  novice  will  probably  sell,  based  on  the  same  pattern  used  when 
buying,  and  will  eventually  lose  money.  These  decisions  were  based  on  inferences  based  on  a  time 
span  that  is  too  short,  leading  the  novice  investor  to  buy  shares  that  are  overvalued  and  sell  these 
shares  when  they  are  undervalued.  According  to  Boroson  (1997),  most  nonprofessional  investors 
follow  this  recipe,  which,  in  most  cases,  leads  to  disastrous  consequences. 

The  example  above  illustrates  a  key  finding  from  research  on  cognitive  psychology  —  people 
usually  tend  to  infer  knowledge  based  on  the  observation  of  a  small  number  of  events,  that  is,  on 
limited  information  (Feldman,  1986).  Moreover,  once  knowledge  structures  are  developed,  changing 
these  structures  can  become  more  difficult  than  developing  them  from  scratch  (Woofford,  1994).  A 
conversation  that  one  of  us  (Ned  Kock)  recently  had  with  a  university  colleague  illustrates  these 
cognitive  biases.  The  colleague  had  gone  to  two  different  agencies  of  the  New  Jersey  Motor  Vehicle 
Services  (MVS)  where  he  met  employees  who  lacked  sympathy  and  friendliness.  He  also  had  gone 
to  a  similar  agency  in  Pennsylvania,  whose  employees  he  found  to  be  very  nice.  Later,  during  a  chat 
with  friends,  he  said: 

“. . .  All  MVS  employees  in  New  Jersey  are  very  grumpy,  difficult  to  deal  with  . . .  The 
state  of  Pennsylvania  is  much  better  in  that  respect ...” 
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He  had  just  made  a  gross  generalization,  given  the  small  sample  of  MVS  agencies  visited — two  in 
New  Jersey  and  only  one  in  Pennsylvania.  Although  he  agreed  this  was  a  generalization,  he  was  never¬ 
theless  adamant  that  he  would  never  go  to  a  New  Jersey  MVS  agency  again,  unless  it  was  absolutely 
necessary.  If  this  was  the  case,  he  said  he  would  ask  a  less  “touchy”  person  to  go  —  his  wife. 

The  development  of  theories  of  knowledge  (or  epistemologies)  and  scientific  methods  of  inquiry 
has  been  motivated  by  a  need  to  overcome  cognitive  biases  as  illustrated  above.  This  has  been  one  of 
the  main  common  goals  of  such  thinkers  as  Aristotle,  Rene  Descartes,  Gottlob  Frege,  Bertrand  Russell, 
Karl  Popper,  and  Thomas  Kuhn.  Epistemologies  and  scientific  methods  have  provided  a  basis  for  the 
conduct  of  research  in  general  and,  in  consequence,  for  technological  advances  that  have  shaped 
organizations  and  society.  Every  year  hundreds  of  billions  of  dollars  are  invested  in  research  with  the 
ultimate  goal  of  generating  highly  reliable  and  valid  knowledge.  And  the  market  value  of  organiza¬ 
tions  is  increasingly  assessed  based  on  the  amount  of  knowledge  that  they  possess  rather  than  on  their 
material  assets  base  (Davidow  and  Malone,  1992;  Toffler,  1991). 

Paul  Strassmann,  a  former  information  technology  executive  at  organizations  such  as  Xerox, 
Kraft  Poods,  and  the  U.S.  Department  of  Defense,  suggests  that  variations  in  the  perceptions  of 
organizational  knowledge  account  for  the  growing  trend  toward  overvaluing  or  undervaluing  com¬ 
mon  stocks  in  the  share  market.  According  to  Strassmann,  the  perception  that  a  stock  is  overvalued 
stems  from  the  failure  of  current  accounting  systems  to  account  for  the  knowledge  assets  of  organiza¬ 
tions,  and  he  presents  an  impressive  array  of  data  to  support  this  idea.  Abbott  Eaboratories  is  one  of 
the  companies  he  used  to  illustrate  this  point. 

Over  a  period  of  7  years  from  1987  to  1994,  the  ratio  between  Abbott’s  market  value  (defined  by 
stock  price),  and  its  equity  has  swung  from  five  up  to  nearly  eight  and  back  down  to  about  seven. 
However,  the  ratio  between  market  value  and  “equity -plus-knowledge  assets”  remained  almost  con¬ 
stant  over  that  period,  smoothly  gravitating  around  two.  This  supports  Strassmann’s  (1997,  p.  13) 
position  that  the  market  perceives  the  accumulation  of  knowledge  assets,  which  is  reflected  in  the 
high  correlation  between  share  prices  of  organizations  and  their  knowledge  assets,  even  though  the 
knowledge  assets  are  not  shown  on  a  company’s  balance  sheet: 

The  sustained  stability  of  the  market-to-capital  ratio,  which  accounts  for  the  steady 
rise  in  the  knowledge  capital  of  Abbott  Eaboratories  confirms  that  the  stock  market 
will  recognize  the  accumulation  of  knowledge  as  an  asset  even  though  the  accoun¬ 
tants  do  not.  The  stock  market  will  also  reward  the  accumulators  of  knowledge  capital 
because  investors  recognize  that  the  worth  of  a  corporation  is  largely  in  its  manage¬ 
ment,  not  its  physical  of  financial  assets. 

When  we  move  from  a  macroeconomic  to  a  microeconomic  perspective  and  look  at  the  business 
processes  of  a  firm,  the  trend  toward  valuing  knowledge  seems  to  be  similar  to  the  one  just  described. 
Knowledge  allows  for  the  prediction  of  process-related  outcomes,  from  the  more  general  prediction 
of  acceptance  of  a  new  product  by  a  group  of  customers  to  much  more  specific  predictions,  such  as 
slight  manual  corrections  needed  on  a  computer  board  surface  after  it  goes  through  an  automatic  drill. 
Correlational  knowledge  enables  process-control  workstation  operators  at  a  chemical  plant  to  link  a 


21 


sudden  rise  of  an  acidity  gauge  to  an  incorrect  setting  of  the  flow  through  a  pipe  valve.  This  enables 
the  operators  to  take  the  appropriate  measures  to  bring  the  acidity  level  down  to  normal. 

The  workers  who  hold  bodies  of  expert  knowledge  are  rewarded  according  to  their  ability  to 
perform  process  activities  in  an  efficient  and  effective  way.  This  is  typically  done  through  linking 
different  types  of  information,  which  can  be  done  through  formal  educational  or  personal  experience 
(i.e.,  the  building  of  mental  knowledge  bases),  and  generating  information  about  the  future  based  on 
information  about  the  past  or  present  (i.e.,  predicting  the  future).  Organizational  wealth  is  closely 
linked  to  the  ability  to  build  and  use  technological  artifacts  to  control  future  states  of  the  (economic, 
physical)  environment  in  which  organizations  operate.  However,  this  control  is  impossible  without 
the  related  ability  to  predict  the  future,  which,  in  turn,  relies  heavily  on  predictive  knowledge. 

Organizational  knowledge  is  believed  to  be  the  single  most  important  factor  that  ultimately  de¬ 
fines  the  ability  of  a  company  to  survive  and  thrive  in  a  competitive  environment  (Davidow  and 
Malone,  1992;  Drucker,  1995).  This  knowledge  is  probably  stored  mostly  in  the  brains  of  the  work¬ 
ers  of  an  organization,  although  it  may  also  be  stored  in  computer  systems  and  databases  (Alster, 
1997;  Strassmann,  1996;  1997)  and  other  archival  records  (e.g.,  printed  reports). 

Whatever  form  it  takes,  knowledge  is  a  commodity;  and,  as  such,  it  can  be  bought  and  sold, 
which  makes  its  value  fluctuate  according  to  the  laws  that  regulate  supply  and  demand.  Abundant 
knowledge,  which  can  be  represented  by  a  large  number  of  available  professionals  with  the  same 
type  of  expertise,  becomes  cheap  when  supply  surpasses  demand,  which  is  typically  reflected  in  a 
decrease  in  the  salaries  of  some  groups  of  professionals.  On  the  other  hand,  a  situation  in  which 
some  types  of  highly  specialized  knowledge  are  in  short  supply,  while  demand  grows  sharply  in  a 
short  period  of  time,  can  lead  the  knowledge  holders  to  be  caught  by  surprise  when  faced  with 
unusually  high  bids  by  employers.  For  example,  Web  Java  programmers  were  being  offered  sala¬ 
ries  of  up  to  $170,000  early  in  1996,  even  though  the  demand  for  their  new  expertise  was  virtually 
nil  until  1995.  This  was  the  year  Java  was  first  released  by  Sun  Microsystems  and  2  years  after  the 
University  of  Illinois  began  the  distribution  of  its  Worldwide  Web  browser  Mosaic. 

Linking  Data,  Information,  and  Knowledge 

Although  they  are  different  conceptual  entities,  data,  information,  and  knowledge  are  inextrica¬ 
bly  connected.  This  may  be  one  of  the  reasons  why  they  are  so  often  confused.  As  discussed  before, 
data  are  perturbations  on  a  communication  or  storage  medium  that  are  used  to  transfer  or  store  infor¬ 
mation  and  knowledge.  Therefore,  knowledge  and  information  can  neither  be  communicated  nor 
stored  without  data. 

Information  is  used  to  describe  the  world  and  can  provide  a  description  of  the  past,  present,  and 
future.  (Information  about  the  future  always  carries  a  certain  degree  of  uncertainty.)  Correlational 
knowledge  allows  for  the  linking  of  different  pieces  of  information  about  the  present.  In  this  case, 
usually  some  of  the  information  pieces  are  obvious  and  are  used  as  a  departure  point;  and  the  other 
pieces  are  hidden  and  allow  for  relevant  decisions.  Predictive  knowledge  enables  the  production  of 
information  about  the  future,  typically  based  on  information  about  the  past  and  the  present;  that  is, 
information  is  generated  based  on  both  correlational  and  predictive  knowledge.  However,  the  reverse 
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relationship  is  also  valid;  that  is,  knowledge  can  be  generated  based  on  information.  In  fact,  the  main 
means  by  which  reliable  knowledge  is  produced  is  the  systematic  analysis  of  information  about  the 
past.  This  analysis  typically  leads  to  the  observation  of  patterns  that  are  combined  into  predictive  and 
associative  rules  (i.e.,  knowledge). 

The  following  case  involves  Hopper  Specialty,  a  retail  vendor  of  industrial  hardware  in 
Farmington,  New  Mexico,  and  NCR,  a  large  developer  of  computer  hardware  and  software,  head¬ 
quartered  in  Dayton,  Ohio,  (Geyelin,  1994).  In  1987,  Hopper  Specialty  decided  to  purchase  a 
computerized  inventory-management  system  from  NCR.  The  system  in  question  was  called,  “Ware¬ 
house  Manager,”  and  it  was  installed  in  1988.  Several  problems  surfaced  immediately  after  the 
system  had  been  installed. 

According  to  Hopper  Specialty’s  representatives,  the  system  never  worked  as  it  was  supposed  to. 
It  displayed  an  assortment  of  problems  such  as  extremely  low  response  times,  constant  locking  up 
of  terminals,  and  corrupted  data  files.  In  1993,  more  than  5  years  after  the  system  was  installed. 
Hopper  Specialty  cancelled  the  contract  with  NCR  and  sued  the  company.  They  claimed  that  they 
had  suffered  a  loss  of  $4.2  million  in  profits  due  to  problems  caused  by  the  installation  and  use  of 
Warehouse  Manager.  NCR’s  lawyers  immediately  asked  that  the  lawsuit  be  dismissed  on  the  grounds 
that  it  was  filed  too  late.  (New  Mexico’s  statute  of  limitations  for  this  type  of  lawsuit  is  only  4 
years.) 

Ethical  considerations  aside,  NCR’s  lawyers  had  access  to  information  and  knowledge  that 
allowed  them  to  safely  move  for  a  case  dismissal.  The  information  to  which  we  refer  here  regards 
New  Mexico’s  statute  of  limitations  and  can  be  expressed  by  the  assertion:  “In  New  Mexico,  a  law 
suit,  such  as  the  one  filed  by  Hopper  Specialty,  should  be  filed  within  at  least  4  years  after  the 
alleged  breach  of  contract  occurs.”  The  knowledge  possessed  by  NCR’s  lawyers  allowed  them  to 
build  a  link  between  information  about  the  law,  in  this  case  the  statute  of  limitations,  and  the  likely 
consequence  (information  about  the  future)  of  grounding  their  defense  on  New  Mexico’s  statute  of 
limitations.  This  knowledge  can  be  summarily  expressed  by  the  rule:  ""If  we  move  for  a  case  dis¬ 
missal  based  on  New  Mexico’s  statute  of  limitations,  then  it  is  likely  that  the  case  will  be  quickly 
dismissed  by  the  judge  presiding  the  case.” 

Figure  4  depicts  the  relationship  between  data,  information,  and  knowledge  based  on  the  case 
discussed  above.  The  following  printed  or  electronic  documents  store  information  that  could  be  used 
by  NCR’s  lawyers  to  defend  their  company  in  the  lawsuit  filed  by  Hopper: 

•  The  lawsuit  notification; 

•  The  contract  between  NCR  and  Hopper; 

•  Warehouse  Manager’s  documentation; 

•  A  legal  database  of  previous  cases ; 

•  Law  books;  and 

•  New  Mexico’s  constitution. 
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Present  information  (lawyers'  brains) 

-Lawsuit  basis 
-Contract  terms 

-New  Mexico's  statute  of  iimitations 


Data  (printed  docs,  eiectronic  databases) 

-Lawsuit  notification 
-Contract  between  NCR  &  Hopper 
-System  documentation 
-Legal  database 
-Law  books 

-New  Mexico's  constitution 


Reasoning 


Future  information  (lawyers'  brains) 

This  case  will  probably  be  dismissed 
based  on  New  Mexico's  statute  of 
limifafions 


Knowledge  (lawyers'  brains) 

If 

a  lawsuit  is  filled  after  the  period 
stipulated  by  the  statute  of  limitations 
then 

there  is  a  good  chance  that  a  judge  will 
dismiss  the  case  upon  request. 


Action  taking: 

Move  for 
case  dismissal 


Figure  4.  The  Relationship  Between  Data,  Information,  and  Knowledge. 


In  Figure  4,  items  are  physical  or  electronic  records  (i.e.,  data  first  read  by  NCR’s  lawyers).  Once 
these  records  were  read,  the  lawyers  could  extract  some  pieces  of  relevant  information  about  the 
present  situation.  Examples  of  such  pieces  of  relevant  information  are  the  terms  of  the  contract  be¬ 
tween  NCR  and  Hopper  and  New  Mexico’s  statute  of  limitations. 


Present  information  can  then  be  combined  with  knowledge  linking  the  main  goal  —  generic 
statute  of  limitations  —  and  the  likely  consequences  of  not  observing  the  stipulated  lawsuit  filing 
expiration  date.  This  combination  of  knowledge  and  information  allows  for  the  prediction  of  the 
future  with  a  certain  degree  of  certainty,  that  is,  the  generation  of  “future  information”  or  information 
about  the  future.  In  the  case  of  NCR  versus  Hopper,  this  future  information  was  the  prediction  that  the 
presiding  judge  would  dismiss  the  case  based  on  New  Mexico’s  statute  of  limitations.  NCR’s  law¬ 
yers,  therefore,  took  the  appropriate  action  of  moving  for  a  case  dismissal. 
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CHAPTER  3 

THE  INFODESIGN  METHODOLOGY 


Underlying  Principles 

InfoDesign’s  underlying  principles  are  tailored  to  the  redesign  of  supply-chain  processes.  The 
term  ""supply  chain”  is  based  on  a  simple  categorization  of  processes  according  to  the  amount  of 
knowledge  transfer  required  during  their  execution.  Processes  can  be  categorized  as  supply-chain 
and  knowledge-intensive  processes.  If  we  built  a  scale  measuring  the  amount  of  knowledge  trans¬ 
ferred  at  execution  time,  these  two  types  of  processes  are  at  different  extremes.  Supply-chain  pro¬ 
cesses  would  be  at  the  lower  end  of  the  scale.  Knowledge-intensive  processes  would  be  at  the  high 
end  (see  Figure  5). 


Supply-chain  Processes  Knowledge-intensive  Processes 

LOW  HIGH 

Amount  of  Required  Knowledge  Transfer  at  Execution  Time 


Figure  5.  Types  of  Processes  According  to  the  Amount  of  Knowledge  Transfer  at  Execution  Time. 

Examples  of  supply-chain  and  knowledge-intensive  processes  are  provided  in  Table  1.  In  addi¬ 
tion  to  the  amount  of  knowledge  transfer,  supply-chain  and  knowledge-intensive  processes  can  be 
differentiated  based  on  their  frequency  and  degree  of  standardization.  Supply-chain  processes  are 
usually  executed  more  frequently  than  knowledge-intensive  processes.  For  example,  an  “order  tak¬ 
ing”  process  is  usually  executed  several  times  a  day  (at  least  once  for  each  product  or  service  sold), 
while  a  “training”  process  takes  place  every  once  in  a  while  (e.g.,  every  quarter).  Supply-chain  pro¬ 
cesses  are  also  usually  more  standardized  than  knowledge-intensive  processes.  For  example,  it  is 
likely  that  there  will  be  better  defined  procedures  to  execute  a  “production”  process  than  to  execute 
“technology  transfer”  processes.  This  is  primarily  due  to  the  fact  that  knowledge-intensive  processes 
are  more  “messy”  and  irregular  than  supply-chain  processes. 

Supply-chain  and  knowledge-intensive  processes  are  closely  related  in  that  the  latter  are  com¬ 
pleted  typically  to  ensure  that  the  former  are  executed  well  and  that  they  generate  expected  outcomes. 
For  example,  a  “training”  process  may  be  executed  to  ensure  that  the  “acquisition”  process  is  ex¬ 
ecuted  according  to  regulations  and  in  an  optimal  way. 


Supply-chain  Processes 

Knowledge-intensive  Processes 

Order  taking 

Training 

Acquisition 

Technology  Transfer 

Production 

Process  Improvement 

Delivery 

Strategic  Planning 

Distribution 

New  Product  Design 

Table  1.  Examples  of  Supply-Chain  and  Knowledge-Intensive  Processes. 
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A  methodology  for  process  redesign  is  necessarily  made  up  of  guidelines  that  are  followed  by 
those  who  employ  it.  Since  those  guidelines  should  be  defined  for  each  step  of  the  methodology, 
there  are  usually  many  of  them,  several  of  which  may  appear  disconnected  and  coming  out  of  no¬ 
where.  Given  this,  it  is  usually  advisable  to  define  key  principles  that  are  used  as  a  basis  for  the 
creation  of  guidelines.  The  InfoDesign  methodology  is  based  on  the  seven  key  principles  outlined 
below:  (For  simplicity,  data,  information,  and  knowledge  are  referred  to  by  the  letters  “D,”  “I,”  and 
“K,”  respectively,  in  this  discussion.) 

The  “Minimum  Data  Proportion” Principle 

•  Maximization  of  the  I/D  and  K/D  ratios  in  data  exchanges  of  supply-chain  processes  leads  to 
lower  communication  losses  and,  thus,  higher  process  productivity. 

For  example,  if  a  data  exchange  using  a  20- field  form  (with  approximately  400  kilobytes  of  data) 
could  transfer  the  same  amount  of  information  and  knowledge  using  a  5-field  form  (with  approxi¬ 
mately  100  kilobytes  of  data),  then  the  5-field  form  would  lead  to  lower  communication  losses  and 
higher  process  productivity.  In  this  case,  higher  communication  losses  would  not  be  due  to  telecom¬ 
munication  costs  but  to  extra  cognitive  effort  and  likely  mistakes  caused  by  the  need  to  filter  relevant 
information  and  knowledge  from  meaningless  data  (Kock,  1999). 

The  “Maximum  Information  Proportion” Principle 

•  Maximization  of  the  I/K  ratio  in  data  exchanges  of  supply-chain  processes  leads  to  lower 
communication  losses  and,  thus,  higher  process  productivity. 

For  example,  if  an  employee  who  is  responsible  for  a  component  activity  of  a  supply-chain  pro¬ 
cess  needs  to  “learn”  how  to  conduct  that  activity  while  executing  it,  more  time  would  be  spent 
communicating  about  the  activity  than  if  only  discrete  pieces  of  information  were  being  exchanged 
(Kock  and  McQueen,  1998;  Kock  et  ah,  1997a). 

The  “Maximum  Shared  Knowledge”  Principle 

•  Maximization  of  shared  K  among  supply-chain  process  agents  leads  to  lower  communication 
losses  and,  thus,  higher  process  productivity. 

For  example,  if  each  member  of  a  six-employee  team,  which  is  responsible  for  the  execution  of  a 
supply-chain  process,  knows  a  great  deal  about  what  the  others  do,  then  their  communication  will 
become  more  efficient,  and  the  productivity  of  the  process,  as  a  whole,  will  be  increased  (Kock, 
1999a). 

The  “Minimum  Data  Transfer  Points”  Principle 

•  Minimization  of  the  number  of  required  data  exchanges  in  supply-chain  processes  leads  to 
lower  communication  losses  and,  thus,  higher  process  productivity. 
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For  example,  if  the  number  of  data  exchanges  (happening  by  means  of  forms,  memos.  E-mails, 
etc.)  in  a  supply-chain  process  could  be  reduced  from  20  to  5  with  no  effect  on  the  information  and 
knowledge  requirements  of  the  process,  then  communication  losses  would  be  reduced  and  productiv¬ 
ity  increased. 

The  “Minimum  Data  Transfer  Costs” Principle 

•  Minimization  of  the  cost  of  data  exchanges  leads  to  lower  overall  supply-chain  process  costs 
and  higher  process  productivity. 

For  example,  if  10  data  exchanges  of  approximately  1  megabyte  each  cost  $100  because  of  the 
use  of  an  expensive  medium  (e.g.,  a  private  mobile-phone  network),  then  the  adoption  of  a  cheaper 
medium  (e.g.,  the  Internet)  will  reduce  their  costs.  This  will,  in  turn,  lead  to  lower  overall  process 
costs  and  increased  process  productivity. 

The  “Quality  versus  Productivity”  Principle 

•  If  quality  is  compromised  to  gain  productivity,  productivity  gains  will  not  materialize  in 
supply-chain  processes. 

For  example,  if  an  increase  in  productivity  in  a  supply-chain  process  leads  to  a  less  desirable 
product,  the  demand  for  that  product  would  go  down.  Thus  the  productivity  increase  would  not 
contribute  to  bottom-line  financial  gains  (Deming,  1986). 

The  “Continuous  Improvement”  Principle 

•  Organizational  changes  that  take  place  outside  the  scope  of  supply-chain  processes  require  the 
supply  chain  to  be  continually  redesigned. 

For  example,  even  if  the  application  of  all  the  previous  principles  leads  to  an  optimized  supply- 
chain  process  today,  it  is  likely  that  the  process  will  not  be  optimal  6  months  to  1  year  from  now. 
Therefore,  measurement  and  review  activities  must  be  incorporated  into  supply-chain  processes  to 
force  continuous  and  incremental  revisions  of  the  processes  to  cope  with  changes  in  the  organiza¬ 
tional  environment  surrounding  the  processes  (Davenport,  1993;  Deming,  1986;  Hammer  and  Champy, 
1993). 

The  principles  discussed  above  provide  a  consistent  and  comprehensive  framework  upon  which 
more  specific  guidelines  for  process  redesign  are  based.  Those  guidelines  are  applied  in  the  context  of 
activities  that  make  up  the  InfoDesign  meta-process,  which  is  discussed  below. 

InfoDesign  at  a  Glance 

InfoDesign  is  a  methodology  to  guide  the  work  of  groups  redesigning  acquisition  processes.  One 
of  its  components  is  a  group  process  (or  meta-process).  As  a  methodology,  InfoDesign  can  be  fully 
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defined  as  a  set  of  aetivities,  guidelines,  and  representation  tools  to  be  used  by  proeess  redesign 
groups.  It  is  suggested  that  group  size  should  be  between  3  to  25  participants  who  play  the  roles  of 
group  leader,  facilitator,  and  ordinary  members.  The  goal  of  the  group  is  to  identify  an  acquisition 
process  where  improvement  opportunities  exist  and  to  propose  changes  that  will  translate  those  op¬ 
portunities  into  practical  improvement. 

InfoDesign  is  made  up  of  three  main  stages:  process  definition,  analysis,  and  redesign.  Each  stage 
comprises  interrelated  activities.  In  order  to  define  the  guidelines  and  representation  tools  to  be  used 
in  InfoDesign,  it  is  important  to  identify  the  activities  in  each  of  the  stages  as  well  as  the  group  roles 
involved.  Group  roles  in  InfoDesign  are  analogous  to  process  functions  in  organizations.  The  activi¬ 
ties  involved  in  each  of  the  stages  are  summarized  below: 

•  Process  Definition  ( Definition  Stage ): 

—  Identify  problems 
—  Identify  processes 
—  Select  a  process  for  redesign 

•  Process  Analysis  (Analysis  Stage): 

—  Model  the  process 
—  Summarize  performance  information 
—  Highlight  opportunities  for  improvement 

•  Process  Redesign  (Redesign  Stage): 

—  Search  for  suitable  changes 
—  Incorporate  changes  into  the  process 

The  illustration  in  Figure  6,  which  follows,  is  a  simplification  of  the  real  meta-process.  The  goal 
of  this  illustration  is  to  provide  a  clear,  yet  limited,  view  of  InfoDesign  as  a  whole.  Loops  and  interac¬ 
tions  with  members  outside  the  group  are  not  represented,  though  these  are  likely  to  occur  in  real 
process  redesign  groups.  For  instance,  while  performing  the  activity  “evaluate  redesign  feasibility,”  a 
group  may  decide  that  it  must  go  back  to  the  activity  “search  for  suitable  changes”  due  to  the  impos¬ 
sibility  of  implementing  some  of  the  proposed  changes.  Also,  the  facilitator  of  a  group  targeting  a 
specific  acquisition  process  in  the  IT  Department  of  an  organization  may  need  information  from  the 
Finance  Department  during  the  stage  “raise  performance  information.” 

Two  permanent  groups  should  be  set  up  by  an  organization  implementing  InfoDesign  in  order  to 
guarantee  the  success  of  process  improvement  groups  —  the  Process  Improvement  Committee  and 
the  Process  Improvement  Support  Team. 

The  Process  Improvement  Committee  analyses  process  redesign  proposals  and,  when  necessary, 
coordinates  and  supports  their  implementation  and  standardization  throughout  the  organization.  The 
Process  Improvement  Committee  members  should  have  enough  authority  to  coordinate  the  imple- 
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mentation  of  strategic  changes,  such  as  those  requiring  large  investments  and  organization-wide  re¬ 
structuring. 

The  Process  Improvement  Support  Team'?,  main  function  is  to  provide  process  improvement 
groups  with  necessary  methodological  and  technological  support.  It  is  also  responsible  for  document¬ 
ing,  organizing,  and  providing  public  access  to  the  information  about  process  improvement  initiatives 
in  the  organization  (e.g.,  documents  generated  by  previous  process  redesign  groups). 

The  InfoDesign  Group 

InfoDesign  comprises  three  group  roles:  leader,  facilitator,  and  member.  A  process  redesign 
group  is  initiated  by  a  self-appointed  leader,  who  should  initially  identify  a  set  of  problems  related 
to  an  acquisition  process  to  be  tackled  by  the  group.  The  group  leader  then  invites  other  members 
to  be  part  of  the  group  and  appoints  one  of  these  members  as  the  group  facilitator.  The  group  leader 
should  advise  the  Process  Improvement  Support  Team  that  the  group  has  been  created,  so  the 
Process  Improvement  Support  Team  can  support  and  document  the  group’s  evolution. 
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The  InfoDesign  Group  Leader 

The  leader  coordinates  the  activities  of  the  group  and  interacts  with  the  Process  Improvement 
Support  Team.  The  responsibilities  of  a  group  leader  include: 

•  Scheduling  meetings  and  making  sure  the  necessary  resources  are  available.  Such  resources 
may  include,  for  instance,  a  room  with  an  overhead  projector  or  an  electronic  conferencing 
system  (in  the  event  the  group  will  meet  primarily  electronically); 

•  Contacting  group  members  and  making  sure  they  are  able  to  attend  the  group  meetings, 
either  face-to-face  or  electronically;  and 

•  Gathering  and  organizing  the  documentation  generated  by  the  group  and,  after  the  process 
redesign  group  has  completed  its  work,  supplying  the  Process  Improvement  Support  Team 
with  this  documentation. 

The  InfoDesign  Group  Facilitator 

The  InfoDesign  group  facilitator  plays  two  roles  at  the  same  time  —  a  support  role  as  well  as  a 
moderator  role.  This  person  is  responsible  for: 

•  Creating  and  maintaining  a  model  of  the  process  targeted  for  redesign,  and 

•  Summarizing  performance  information  about  the  process  and  highlighting  opportunities  for 
improvement. 

To  meet  these  responsibilities,  the  facilitator  must  have  a  thorough  understanding  of  InfoDesign’s 
guidelines  and  representation  tools.  The  facilitator  does  not  make  decisions  alone  on  the  adoption  of 
specific  changes;  this  is  a  prerogative  of  the  InfoDesign  group  as  a  whole  and  must  be  achieved  by 
consensus. 

The  InfoDesign  Group  Member 

The  other  members  of  the  group  (i.e.,  the  “ordinary”  members)  will  provide  their  inputs  through¬ 
out  the  group  discussion  in  a  “low-cost”  participation  manner.  As  in  most  types  of  moderated  group 
discussions,  the  majority  of  the  burdens  of  coordinating  communication,  compiling  member  contri¬ 
butions,  and  documenting  group  decisions  are  on  the  leader  and  the  facilitator.  One  person  can  play 
more  than  one  role  in  the  group.  For  example,  one  person  can  be  the  group  leader,  the  facilitator,  and 
provide  inputs  as  a  group  member. 

General  Guidelines  for  InfoDesign 

Guidelines  are  “how-to”  rules  that  can  refer  to  the  InfoDesign  meta-process,  as  a  whole,  or  its 
component  activities.  Guidelines  follow  that  relate  to  the  InfoDesign  meta-process  as  a  whole;  they 
are  not  specific  to  a  particular  activity. 
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•  The  process  improvement  group  should  develop  a  redesign  proposal  in  a  limited  amount  of 
time,  ideally  in  no  more  than  8  weeks.  Previous  research  shows  that  an  acceptable  “average” 
time  is  3  weeks  (Kock  and  McQueen,  1995). 

•  The  stages  a  process  redesign  group  goes  through  should  be  documented.  The  leader  is  prima¬ 
rily  responsible  for  this  documentation,  which  is  essential  to  building  historical  documentation 
about  organizational  process  redesign  initiatives.  This  information  can  be  used  for  many  pur¬ 
poses,  such  as  a  basis  for  future  process  redesign  groups  and  as  evidence  of  the  organization’s 
commitment  to  improving  process  quality  in  quality  accreditation  audits.  For  example,  the 
organization  may  use  process  improvement  group  documentation  in  ISO-9000  certification 
audits  to  show  that  exemplary  procedures  for  dealing  with  “nonconformities”  were  followed 
(Kock  and  McQueen,  1997). 

•  Each  of  the  group  meetings  should  conclude  with  a  link  to  the  next  meeting.  A  meeting  where 
the  activities  “identify  problems”  and  “identify  processes”  are  accomplished  should  end  with 
a  preliminary  selection  of  a  process  to  be  redesigned.  This  preliminary  selection  works  as  a 
link  to  the  next  meeting,  where  the  first  activity  will  be  “select  a  process  for  redesign.”  These 
“links”  between  meetings  are  aimed  at  improving  group  focus. 

•  The  facilitator  should  not  try  to  enforce  the  group  process  (i.e. ,  InfoDesign)  described  in  this 
document.  Instead,  this  person  should  induce  it  in  a  “transparent”  way.  In  most  cases,  this  will 
occur  almost  naturally  as  the  facilitator  is  responsible  for  several  of  the  key  activities  of  the 
process  redesign  group. 

InfoDesign  in  Detail:  Activities,  Guidelines,  and  Representation  Tools 

The  following  subsections  provide  a  discussion  of  each  of  the  activities  in  InfoDesign,  including 
guidelines  and  representation  tools  used.  (Subsection  titles  are  formed  by  the  main  stage,  which  is 
followed  by  a  colon  and  the  name  of  the  activity.) 

Definition  Stage:  Identify  Problems 

In  the  definition  stage,  the  first  group  activity  is  to  identify  problems.  As  discussed  before,  the 
person  who  first  brings  the  problems  up  for  discussion  is  a  self-appointed  group  leader.  Virtually 
anyone  can  be  a  group  leader,  which  helps  spread  the  responsibility  for  the  innovation  over  the 
organization  and  reduces  the  innovation’s  reliance  on  managers.  This  broadens  the  process 
improvement’s  scope  of  application  as  the  number  of  managers  in  one  organization  is  usually  smaller 
than  that  of  line  employees. 

In  some  forms  of  process  improvement  where  the  improvement  is  gradual  and  accomplished  by 
permanent  groups  (e.g.,  quality  circles),  the  search  for  improvement  does  not  necessarily  rely  on  the 
previous  identification  of  problems.  In  these  cases  the  improvement  is  routinely  sought  based  on  the 
assumption  that  every  process  can  always  be  improved  in  one  way  or  another.  However,  research 
shows  that  the  identification  of  problems  as  sources  of  discontent  within  the  organization  is  a  success 
factor  in  process  improvement  (Hall  et  ah,  1993). 
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The  identification  of  problems  fosters  interest  in  process  improvement  among  organization 
members  and,  at  the  same  time,  gives  them  an  idea  of  what  is  to  be  achieved  with  the  improve¬ 
ment.  The  identification  of  problems,  though,  is  only  the  beginning  of  InfoDesign.  The  main 
outcome  of  InfoDesign  is  process  improvement,  not  problem  solving.  The  identification  of  prob¬ 
lems  is  an  intermediate  step  that  leads  to  the  selection  of  a  process  for  improvement  (Harrington, 
1991). 

Guidelines 


•  Generate  a  list  of  interrelated  problems,  and  submit  it  to  the  process  improvement  group  so 
mistakes  and  omissions  can  be  corrected.  The  group  leader  should  prepare  the  preliminary 
version  of  the  list.  This  is  the  first  step  in  the  formation  of  the  group. 

•  Concurrently  with  the  generation  of  the  list  mentioned  above,  the  leader  should  invite  pro¬ 
spective  group  members.  Listing  problems  and  inviting  group  members  are  two  interrelated 
tasks.  Expect  little  involvement  from  group  members  who  have  no  interest  in  the  problems 
initially  listed. 

•  Problems  in  the  list  should  be  at  least  intuitively  related.  A  list  of  problems  that  is  excessively 
broad  and  involves  several  different  areas  of  an  organization,  for  example,  leads  to  the  identi¬ 
fication  of  several  processes  for  redesign.  This  is  likely  to  disperse  the  focus  of  the  process 
improvement  group. 

•  Problems  should  be  approached  in  a  very  clear  and  open  way.  There  should  be  no  fear  of 
disclosing  discontent  with  the  actual  situation.  Poor  identification  of  problems  (e.g.,  certain 
problems  are  not  discussed  because  they  may  upset  some  individuals)  leads  to  poor  process 
redesign  (Deming,  1986;  Kock  and  Tomelin,  1996). 

Definition  Stage:  Identify  Processes 

Once  a  list  of  interrelated  problems  is  identified,  the  next  step  is  to  identify  the  processes  associ¬ 
ated  with  those  problems.  At  this  point  it  may  be  found  that  some  processes  are  clearly  defined,  while 
others  are  not  (Wastell  et  al.,  1994).  For  instance,  it  may  be  found  that  several  problems  are  associated 
with  the  activity  “inform  bidders  about  the  outcomes  of  the  review  of  bids,”  which  was  not  previously 
seen  as  part  of  a  set  of  interrelated  activities. 

Guidelines 


•  A  process  improvement  group  should  not  try  to  build  process  models  in  this  activity.  In¬ 
stead,  the  interrelated  activities  that  are  perceived  by  the  group  as  the  causes  of  problems 
should  be  listed  using  one  or  a  few  words.  For  example,  the  acquisition-related  problems 
listed  may  be  “late  invoices,”  “customer  complaints  about  invoice  complexity,”  “inaccurate 
invoices,”  and  “late  payment.”  As  these  are  all  related  to  the  process  of  issuing  invoices,  the 
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processes  can  be  simply  described  in  this  activity  as  “invoicing.”  Later,  in  the  second  stage 
of  InfoDesign  —  the  process  analysis  stage  —  the  selected  process  or  processes  will  be 
analyzed  in  more  detail. 

•  A  process  improvement  group  should  not  expect  to  identify  one  process  for  each  problem 
or  vice-versa.  The  relationship  between  problems  and  processes  may  be  a  “many-to-many” 
one.  That  is,  several  processes  can  cause  one  problem;  and,  conversely,  several  problems 
can  be  caused  by  one  process.  Thus,  even  though  the  initial  list  of  problems  may  have 
only  “one”  problem,  it  may  help  in  the  identification  of  several  processes  for  improve¬ 
ment. 

Definition  Stage:  Select  a  Process  for  Redesign 

This  activity  is  a  conclusion  of  the  work  started  in  the  previous  activity,  “identify  processes.” 
Here,  one  of  the  processes  identified  in  that  activity  will  be  chosen  for  redesign. 

When  several  processes  are  identified,  group  members  may  want  to  select  more  than  one  process 
for  improvement.  This  is  frequently  the  case  when  there  are  no  clear  boundaries  between  processes 
within  the  organization.  However,  as  the  number  of  selected  processes  increases,  so  does  the  com¬ 
plexity  in  the  next  stage,  “process  analysis.”  An  additional  drawback  of  the  selection  of  many  pro¬ 
cesses  for  redesign  is  the  high  number  of  changes  likely  to  be  proposed  by  the  group.  A  high  number 
of  processes  selected  for  redesign  may  hinder  the  process  improvement  group  from  focusing  on  one 
specific  process  that  needs  urgent  attention.  It  may  also  reduce  the  level  of  care  given  to  the  analysis 
and  redesign  of  each  individual  process. 

Guidelines 


•  The  process  improvement  group  should  strive  to  select  as  few  processes  as  possible.  Ideally, 
only  one  process  should  be  selected. 

•  The  process  that  is  associated  with  the  most  critical  problems  should  be  given  priority  in  the 
selection. 

•  After  applying  the  preceding  guidelines,  the  process  that  is  associated  with  the  highest  number 
of  problems  should  be  given  priority  in  the  selection. 

Analysis  Stage:  Model  the  Process 

In  this  activity  the  process  considered  for  improvement  by  the  process  improvement  group  is 
modeled  using  two  process  representation  tools.  The  goal  of  this  activity  is  to  understand  the  relation¬ 
ships  between  process  activities  and  to  obtain  a  clear  view  of  the  process  as  a  whole. 
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Representation  Tool:  Activity  Table 


The  activity  table  provides  a  first  step  in  the  process  modeling  activity  and  sets  the  stage  for  the 
development  of  the  InfoDesign  diagram,  which  is  discussed  in  the  next  section.  An  example  of  an 
activity  table,  based  on  a  software  development  acquisition  process,  is  provided  in  Figure  7.  A 
typical  activity  table  has  five  columns.  The  first  column,  on  the  left,  shows  the  number  of  each 
activity.  The  other  four  columns  are  titled,  “What,”  “When,”  “Who,”  and  “How.”  In  the  “What” 
column,  each  activity  is  briefly  described  by  a  transitive  verb  in  the  infinitive  form  followed  by  its 
object.  The  “When”  column  indicates  when  the  activity  is  conducted  —  this  is  usually  done  by 
specifying  what  activity  or  activities  immediately  precede  the  current  activity.  The  “Who”  column 
indicates  who  performs  the  activity  —  usually  by  means  of  an  organizational  function  (e.g.,  techni¬ 
cal  lead)  or  a  group  within  the  organization  (e.g.,  contracts  department).  The  “How”  column  is  a 
memo-type  column  where  a  description  of  how  the  activity  is  conducted  is  provided  —  usually 
specific  tools  or  artifacts  used  in  the  activity  are  indicated  in  this  column  (e.g.,  automated  proposal 
preparation  system). 


# 

What 

When 

Who 

How 

1 

Receive  Request  for 
Proposal  (RFP) 

Beginning  of 
process 

Contracts  Manager 

Using  Secure  Workflow  process  from 
customers’  Contracts  Officer 

2 

Announce  RFP 

After  1 

Contracts  Manager 

Using  E-mail  and  highlighting  suspense 
date  (due  date)  requested  by  customer 

3 

Prepare  proposal 

After  2 

Technical  Lead,  Contracts 
Manager,  Finance  and 
Accounting 

Using  automated  proposal  preparation 
system 

4 

Prepare  Basis  of 
Estimate  (BOE) 

After  2 

Technical  Lead 

Using  historical  data  and  BOE  template 
(MS  Word) 

Figure  7.  Example  of  Activity  Table. 


Developing  an  activity  table  is  a  preliminary  step  that  may  or  may  not  be  taken  by  an  InfoDesign 
group.  The  goal  is  to  give  the  group  a  basic  idea  of  what  the  process  looks  like  using  a  simple  text- 
based,  work-flow  representation.  The  next  step  is  the  development  of  an  InfoDesign  diagram  to  show 
how  information  and  knowledge  flow  and  are  stored  in  the  process.  Assuming  that  information  and 
knowledge  flow  and  they  are  stored  by  means  of  data  items,  data  flows  are  not  represented  explicitly 
in  InfoDesign  diagrams. 
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Representation  Tool:  InfoDesign  Diagram 


An  InfoDesign  diagram  is  made  up  of  a  combination  of  the  four  symbols  shown  in  Figure  8.  The 
“process  agent”  symbol  represents  an  organizational  function  that  plays  a  role  in  an  acquisition  pro¬ 
cess.  The  “process  activity”  symbol  represents  an  activity  that  makes  up  an  acquisition  process.  The 
“IK  flow”  symbol  represents  the  flow  of  information  and/or  knowledge  in  an  acquisition  process. 
Finally,  the  “IK  store”  symbol  represents  an  information  and/or  knowledge  “store”  of  an  acquisition 
process.  A  “store”  can  be  any  repository  that  stores  information  and  knowledge  through  data  in  a 
temporary  or  permanent  way. 


Process  Agent 


► 


IK  Flow 


Process  Activity 


Figure  8.  InfoDesign  Diagram  Symbols. 

(IK  =  Information  and  Knowledge) 


A  process  agent  usually  carries  out  one  or  more  activities  in  an  acquisition  process.  Some  activi¬ 
ties  may  be  carried  out  without  human  intervention  (i.e.,  automatically)  and  still  be  represented  in  an 
InfoDesign  diagram  using  “process  activity”  symbols.  Activities  can  be  “exploded”  into  other  activi¬ 
ties  in  “lower-level”  InfoDesign  diagrams.  That  is,  an  acquisition  process  can  be  represented  by 
several  InfoDesign  diagrams,  each  modeling  the  acquisition  process  at  different  levels  of  detail.  The 
highest- level  InfoDesign  diagram  is  the  level  1  InfoDesign  diagram.  In  a  level  1  InfoDesign  diagram, 
activities  are  numbered  from  I  to  N,  N  being  the  number  of  activities  represented  in  an  InfoDesign 
diagram.  These  numbers  should  indicate  the  sequence  of  execution  of  activities  in  an  acquisition 
process  in  an  approximate  way. 

If  an  acquisition  process  activity  seems  too  complex  to  be  understood  without  further  decompo¬ 
sition,  then  it  can  be  “exploded”  into  a  separate  InfoDesign  diagram.  Let’s  assume  that  activity  2  of 
an  acquisition  process  is  very  complex.  This  activity  can  be  “exploded”  into  a  level  2  InfoDesign 
diagram,  where  the  component  activities  will  be  numbered  2.1,  2.2,  2.3,  and  so  on.  If  one  of  the 
activities  of  this  level  2  InfoDesign  diagram  (say  activity  2.3)  is  too  complex  and  needs  to  be 
“exploded,”  a  level  3  InfoDesign  diagram  can  be  created.  The  component  activities  of  level  3  will  be 
numbered  2.3.1,  2.3.2,  2.3.3,  etc. 

The  InfoDesign  diagram  incorporates  all  the  elements  of  the  activity  table,  as  well  as  other  ele¬ 
ments  that  indicate  how  information  and  knowledge  are  stored  and  how  they  flow  in  an  acquisition 
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process.  An  example  of  InfoDesign  diagram,  based  on  a  software  development  acquisition  process,  is 
provided  in  Figure  9.  Only  part  of  the  process  is  shown  in  Figure  9;  the  emphasis  is  on  the  communi¬ 
cation  of  a  Request  for  Proposals  (RFPs)  from  a  Department  of  Defense  (DoD)  branch  to  a  software 
development  contractor^  and  the  internal  activities  at  the  contractor  that  immediately  follow  this  com¬ 
munication. 


Notes: 

•  Alpha  Negotiations:  Initial  negotiations  between  DoD  Branch  and 
Technical  Lead  to  define  the  budget  for  the  project 

•  DoD:  U.S.  Department  of  Defense 


RFP:  Request  for  Proposal 
RFPA:  RFP  Announcement 

Secure  Workforce:  DoD  Branch  application  that  allows  selective 
access  to  RFPs 


Figure  9.  Example  of  InfoDesign  Diagram. 

(IK  =  Information  and  Knowledge) 


Guidelines 


•  The  description  within  a  “process  activity”  symbol  should  be  as  brief  as  possible  and  begin 
with  a  verb  in  the  infinitive  form  (e.g.,  download  RFP,  announce  RFP,  prepare  draft  proposal, 
conduct  Alpha  Negotiations,  drill  a  computer  card,  load  a  batch  of  parts  onto  a  truck,  etc.). 


^The  diagram  is  based  on  a  Computer  Sciences  Corporation  (CSC)  process  redesign  project;  one  of  the  authors  was 
involved  in  this  project. 
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•  An  InfoDesign  diagram  should  have  a  limited  number  of  symbols  so  it  is  not  too  complex 
for  someone  who  did  not  participate  in  its  development.  Studies  on  human  cognition  limita¬ 
tions  provide  the  basis  for  establishing  an  optimum  number  of  symbols  in  process  modeling 
diagrams  (Miller,  1956).  These  studies  suggest  that  this  number  should  be  between  5  and  9 
symbols  (i.e.,  7  plus  or  minus  2).  When  a  process  cannot  be  represented  with  less  than  14 
symbols  (i.e.,  twice  the  optimum  average)  due  to  its  complexity,  some  of  the  activities  should 
be  “exploded”  into  lower-level  InfoDesign  diagrams  (Pressman,  1987). 

•  Trivial  artifacts  should  not  be  described  in  “process  activities”  (e.g.,  pen  and  paper,  telephone, 
etc.).  A  rule  of  thumb  is  to  describe  only  artifacts  that  are  specific  to  an  activity  (or  type  of 
activity)  and  without  which  the  activity  could  not  be  carried  out  (e.g..  Secure  Work  Flow  (a 
computer  system  shown  in  Figure  9),  lathe,  computerized  drill,  cheese  processor,  inventory 
control  system,  etc.).  An  artifact  is  specific  to  an  activity  or  type  of  activity  whenever  it  has 
been  designed  to  support  only  that  activity  or  type  of  activity. 

•  When  modeling  a  process,  the  facilitator  should  not  be  afraid  of  adding  handwritten  notes  and 
marks  to  the  diagram  if  they  are  needed  to  clarify  certain  points.  The  emphasis  should  be  on 
using  the  graphical  tool  in  an  effective  way  to  convey  information  and  knowledge  that  will 
allow  the  group  to  redesign  the  process  rather  than  in  a  “rule- abiding”  way.  Keep  the  chart  as 
neat  and  tidy  as  possible  by  strictly  sticking  with  the  charting  symbolism. 

Analysis  Stage:  Summarize  Performance  Information 

In  this  activity,  information  about  the  performance  of  the  process  is  summarized  for  the 
InfoDesign  group.  This  information  should  gravitate  around  two  main  process  attributes  —  quality 
and  productivity.  A  direct  measure  of  process  quality  is  customer  satisfaction,  so  the  best  way  to 
evaluate  it  is  to  obtain  information  on  how  the  customers  of  the  process  perceive  its  outputs.  The 
customers  of  an  acquisition  process  are  those  inside  and  outside  the  organization  who  receive 
outputs  generated  by  activities  of  the  process.  Such  outputs  may  include  budgets,  proposals,  speci¬ 
fications,  project  plans,  etc.  For  example,  a  well-prepared,  high-quality  budget  is  a  budget  that  not 
only  meets  the  requirements  of  the  project  at  the  lowest  possible  cost  for  the  buyer  but  also  does  not 
fall  below  the  specified  requirements.  Similarly,  a  budget  that  is  lower  than  is  necessary  to  meet  all 
the  requirements  of  the  project  under  bid  is  likely  to  lead  to  the  delivery  of  low-quality  outputs  or  to 
the  delivery  of  no  outputs  at  all. 

Productivity  is  traditionally  measured  by  the  ratio  outputs/inputs  (Misterek  et  ah,  1992).  This 
means  that  an  acquisition  process  that  employs  10  people  and  completes  2  acquisition  “units” 
(i.e.,  an  arbitrary  metric  used  to  count  acquisitions)  per  month  may  be  said  to  have  a  productivity 
of  2/10  =  0.2  acquisition  units  per  month  per  employee.  If  the  same  process  is  redesigned  so  it 
can  complete  the  same  2  acquisition  units  per  month  but,  now,  with  5  employees,  then  its  pro¬ 
ductivity  will  be  2/5  =  0.4  acquisition  units  per  month  per  employee.  That  is  100  percent  higher 
than  before. 
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A  better  way  to  measure  process  productivity  is  by  considering  the  ratio  (production  capacity)/ 
(production  costs).  This  offers  two  advantages  against  the  (input/output)  approach  discussed  above: 

•  It  considers  the  costs  of  the  inputs  to  the  process  and  not  their  quantity,  and 

•  It  takes  into  consideration  the  capacity  of  a  process  and  not  its  realization . 

Even  when  its  cost  is  reduced,  the  quantity  of  each  input  may  remain  the  same  due  to  process 
improvement.  For  example,  an  acquisition  process  may  benefit  from  a  smarter  use  of  less  expensive 
information  technologies,  whether  the  number  of  acquisition  units  is  reduced  or  not.  This  is  why  the 
analysis  of  cost  is  critical  to  productivity  measurement  as  opposed  to  the  approach  of  counting  the 
number  of  inputs.  Yet,  this  approach  implies  a  higher  measurement  complexity  as  costs  can  vary 
considerably  with  time. 

The  measurement  of  the  production  capacity  for  a  process  implies  forecasting.  To  say  that  an 
acquisition  process  has  a  production  capacity  of  300  acquisition  units  a  year  means  that  the  acquisi¬ 
tion  process  can  produce  that  figure  on  average  but  not  that  it  is  the  real  average  output.  Since  produc¬ 
tion  in  real  contexts  depends  on  consumption  expectancy,  which  in  turn  is  based  on  the  buyer’s 
budget  and  needs,  the  simple  measure  of  outputs  can  lead  to  wrong  assumptions  about  productivity. 
This  risk  is  suppressed  when  productivity  assessment  is  based  on  production  capacity  (Goldratt  and 
Fox,  1986).  Complexity  here  is,  again,  increased  by  the  need  to  estimate  process  output  capacity 
based  on  historical  figures  and  resource  capacity  of  specific  units.  However,  in  many  cases  this  may 
be  easier  than  relying  on  real  numbers  with  measurements  that  are  severely  hampered  by  the  added 
cost  of  extensions  in  the  accounting  system  of  the  organization  (Mark,  1984). 

So,  the  analysis  of  productivity  should  be  based  on  estimates  of  production  capacity  and  costs 
rather  than  on  outputs  and  inputs.  While  likely  to  add  complexity  to  measurement,  this  is  useful 
because  it  draws  a  line  between  productivity  and  quality  assessment.  The  output/input  approach 
disregards  the  fact  that  quality  improvement  is  bound  to  generate  more  consumption  and,  conse¬ 
quently,  promote  an  increase  in  output  (Doming,  1986).  By  connecting  productivity  with  the  actual 
outputs  produced  by  a  process,  one  could  mistake  quality  for  productivity  improvement.  This  is 
particularly  true  when  a  surge  in  demand,  due  to  higher  quality,  is  simply  supported  by  excess  capac¬ 
ity,  not  augmented  productivity. 

Guidelines 


•  In  the  first  activity  of  InfoDesign  —  the  one  aimed  at  identifying  problems  —  the  group 
should  have  gathered  information  on  process  customer  complaints.  In  this  activity,  the  facilita¬ 
tor  should  try  to  find  quantitative  data  associated  with  those  complaints  and  should  try,  for 
example,  to  identify,  by  means  of  quantitative  measures,  the  problems  customers  see  as  the 
most  critical  and  as  occurring  the  most  often. 

•  In  this  activity,  the  facilitator  should  not  be  concerned  with  generating  performance  informa¬ 
tion.  The  facilitator  should,  instead,  focus  on  summarizing  existing  information  about  the  pro¬ 
cess  performance.  This  information  may  come  from  areas  of  the  organization  that  are  not 
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represented  in  the  process  improvement  group.  Generating  performance  information  may  take 
too  long  and,  therefore,  make  the  process  improvement  group  lose  momentum.  A  lack  of 
process  performance  information,  identified  by  a  group  in  its  analysis  stage,  may  become  a 
problem  to  be  tackled  by  a  different  process  improvement  group. 

Analysis  Stage:  Highlight  Improvement  Opportunities 

Based  on  performance  information  raised  in  the  previous  activity,  the  facilitator  highlights  oppor¬ 
tunities  for  improvement  in  this  activity.  This  is  helpful  in  leading  the  InfoDesign  group  towards  the 
discussion  of  concrete  changes  to  improve  the  process. 

Guideline 


The  facilitator  should  highlight  process  improvement  opportunities  by  proposing  changes  in  the 
process  to  be  discussed  by  the  group.  These  changes  should  be  based  on  the  information  gathered 
during  the  two  previous  activities,  namely,  “model  the  process”  and  “raise  performance  evaluation.” 
They  should  also  follow  the  guidelines  “search  for  suitable  changes”  discussed  in  the  next  activity. 

Redesign  Stage:  Search  for  Suitable  Changes 

In  this  activity  group  members  propose  suitable  changes  in  the  process  so  improvements  of  qual¬ 
ity  and  productivity  can  be  achieved.  The  literature  on  process  improvement  provides  several  guide¬ 
lines  for  making  improvements.  These  guidelines  can  help  process  improvement  group  members 
formulate  their  redesign  proposals. 

Guidelines 


Harrington  (1991)  provides  several  guidelines  for  process  improvement  based  on  general  prin¬ 
ciples  such  as  process  and  activity  simplification,  bureaucracy  elimination,  standardization,  and  tech¬ 
nology  utilization.  Hall  et  al.  (1993)  and  Venkatraman  (1994)  propose  guidelines  for  redesigning 
processes  according  to  improvement  dimensions  and  scope  levels.  Guha  et  al.  (1993)  and  Wastell  et 
al.  (1994)  present  some  process  improvement  guidelines  as  part  of  specific  process  redesign  pro¬ 
grams.  Dingle  (1994)  and  Caron  et  al.  (1994)  draw  guidelines  from  the  analysis  of  process  reengineering 
cases.  Kock  (1999a)  summarizes  these  guidelines  and  proposes  several  of  his  own,  based  on  the 
analysis  of  face-to-face  and  computer-mediated  process  improvement  groups.  The  guidelines  below 
build  on  this  body  of  normative  work;  they  are  organized  around  the  seven  principles  discussed 
earlier  in  this  chapter. 

•  Maximize  the  I/D  (information/data)  and  K/D  (knowledge/data)  ratios  in  data  exchanges. 

This  can  be  achieved  by  analyzing  each  data  exchange  (e.g.,  form,  memo,  etc.)  and  elimi¬ 
nating  data  components  that  are  not  used  (i.e.,  not  processed).  For  example,  a  project 
requirements  form  of  a  call  for  proposals  may  contain  20  different  fields,  but  only  5  of 
those  fields  are  actually  used  by  those  who  are  going  to  prepare  a  draft  proposal.  In  this 
case,  the  number  of  fields  on  the  form  should  be  reduced  to  5,  which  are  the  fields  that  are 
actually  used. 
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•  Maximize  the  I/K  (information/knowledge)  ratio  in  routine  data  exchanges.  This  can  be 
achieved  by  eliminating  the  knowledge  content  in  routine  data  exchanges  and  creating  special 
processes.  These  processes  are  external  and  ancillary  to  the  acquisition  process  being  consid¬ 
ered,  and  their  main  goal  is  knowledge  sharing.  These  special  processes  will  likely  limit  the 
need  for  the  exchange  of  knowledge  content  in  routine  data  exchanges,  which  has  been  shown 
to  negatively  affect  process  productivity  (Kock  and  McQueen,  1998). 

•  Maximize  shared  K  (knowledge)  among  processes.  As  discussed  above,  this  can  be  achieved 
by  creating  special  processes  whose  main  goal  is  knowledge  sharing.  One  type  of  process  that 
has  been  shown  to  be  conducive  to  knowledge  sharing  is  “process  improvement”  (Kock, 
1999a).  Thus,  using  a  methodology,  such  as  InfoDesign,  is  likely  to  increase  the  amount  of 
knowledge  that  process  agents,  who  worked  as  process  improvement  teams,  share  about  the 
process  they  participated  in. 

•  Minimize  the  number  of  required  data  exchanges.  This  can  be  achieved  by  eliminating 
duplication  of  information  and  reducing  information  flow,  control,  and  the  number  of  contact 
points  in  the  process. 

—  Eliminating  duplication  of  information  is  particularly  important  in  static  repositories  (e.g.,  a 
database  of  suppliers)  as  opposed  to  dynamic  repositories  (e.g.,  a  supplier  data  entry  form) 
because  the  former  hold  information  on  a  more  permanent  basis.  Duplication  of  informa¬ 
tion  in  different  static  repositories  often  creates  inconsistency  problems,  which  may  have  a 
negative  impact  on  productivity  and  quality  and  lead  to  unnecessary  exchanges  of  data  in 
acquisition  processes. 

—  Reducing  information  flow  is  key  to  minimizing  the  number  of  required  data  exchanges 
since  data  exchanges  take  place  primarily  so  information  can  be  transferred,  usually  be¬ 
tween  people.  Information  flow  reduction  can  be  achieved  by  selecting  the  information  that 
is  important  in  acquisition  processes  and  eliminating  the  rest.  Information  flow  can  also  be 
reduced  by  effectively  using  group  support  and  database  management  systems.  Thus,  in¬ 
formation  can  flow  across  several  hierarchical  levels  without  the  need  for  filtering  and 
“poligonation”  (i.e.,  information  that  needs  to  go  from  individual  A  to  individual  B,  first 
going  to  one  or  more  individuals  who  simply  forward  the  information  to  the  next  person). 
(See  Kock,  1999a.) 

—  Reducing  control  is  important  because  control  activities  lead  to  unnecessary  exchanges  of 
data.  Moreover,  while  some  control  activities  are  crucial  to  prevent  major  problems  from 
happening,  others  are  not;  and  they  add  little  or  no  value  to  customers.  The  latter  are  often 
designed  to  prevent  problems  from  happening  as  a  result  of  human  mistakes.  In  several 
cases,  however,  control  itself  fosters  neglect  and  can  have  a  negative  impact  on  productiv¬ 
ity.  Additionally,  some  types  of  control,  such  as  those  aimed  at  preventing  fraud,  may  prove 
to  be  more  costly  than  no  control  at  all. 

—  Finally,  reducing  the  number  of  contact  points  in  an  acquisition  process  is  likely  to  reduce 
the  number  of  required  data  exchanges  because  many  contact  points  include  data  exchanges. 
Contact  points  can  be  defined  as  points  where  there  is  interaction  among  two  or  more 
people.  Contact  points  generate  delays  and  inconsistencies  and,  when  in  excess,  lead  to 
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process  customer  perplexity  and  dissatisfaction.  Additionally,  it  is  much  easier  to  monitor 
customer  perceptions  in  situations  where  there  are  a  small  number  of  contact  points.  This 
makes  it  easier  to  improve  process  quality. 

•  Minimize  the  cost  of  data  exchanges.  There  are  a  number  of  different  ways  this  can  be 
achieved  through  the  smart  implementation  of  information  technologies.  From  a  conceptual 
perspective,  however,  one  of  the  key  ways  this  can  be  achieved  is  by  fostering  asynchronous 
communication.  When  people  exchange  information  or  knowledge,  they  can  do  it  synchro¬ 
nously  (i.e.,  interacting  at  the  same  time)  or  asynchronously  (i.e.,  interacting  at  different  times). 
One  example  of  synchronous  communication  is  a  telephone  conversation.  If  the  conversation 
takes  place  via  E-mail,  it  then  becomes  an  example  of  asynchronous  communication.  It  has 
been  observed,  especially  in  formal  business  interaction,  that  asynchronous  communication  is 
more  efficient  almost  always.  On  the  other  hand,  synchronous  communication  often  leads  to 
wasted  time  (e.g.,  waiting  for  the  other  person  to  be  found),  and  communication  tends  to  be 
less  objective.  Asynchronous  communication  can  be  implemented  with  simple  artifacts  such 
as  in-boxes  and  out-boxes,  fax  trays,  and  billboards.  These  artifacts  work  as  dynamic  informa¬ 
tion  repositories. 

•  Maximize  quality.  The  “quality  versus  productivity”  principle  argues  that,  if  quality  is  compro¬ 
mised  so  productivity  gains  can  be  achieved,  productivity  gains  will  not  materialize.  The  focus 
of  the  process  redesign  guidelines  discussed  so  far  has  been  on  the  increase  of  process  productiv¬ 
ity  by  focusing  on  data,  information,  and  knowledge.  This  guideline,  “maximize  quality,”  is  a 
“moderating”  guideline  in  that  it  moderates  the  application  of  the  other  guidelines.  The  applica¬ 
tion  of  the  “maximize  quality”  guideline  should  begin  with  a  question  during  the  application  of 
each  of  the  previous  guidelines  in  a  real  acquisition  process.  Ask  if  the  resulting  process  change 
is  going  to  have  a  negative  impact  on  quality.  If  it  is,  then  the  implementation  of  the  process 
change  under  consideration  should  be  reconsidered  and,  if  necessary,  abandoned. 

•  Incorporate  “continuous  improvement”  activities  into  the  process.  The  “continuous  im¬ 
provement”  principle  argues  that  organizational  changes  that  take  place  outside  processes 
require  the  continuous  redesign  of  processes.  The  process  redesign  guidelines  discussed  here 
are  aimed  at  discrete  or  “one-shot”  process  improvement.  Nevertheless,  continuous  improve¬ 
ment  is  also  necessary  (Kock,  1999a)  to  both  refine  the  “one-shot”  changes  resulting  from  an 
InfoDesign  project  and  allow  for  small  and  incremental  process  changes  to  take  place  over 
time  in  response  to  changes  that  take  place  outside  the  process.  This  can  be  achieved  by 
incorporating  three  types  of  activities  into  the  new  process:  (1)  process  performance  measure¬ 
ment  activities,  (2)  process  performance  review  activities,  and  (3)  process  revision  activities. 
The  frequency  of  these  activities  should  be  lower  than  that  of  the  process  itself.  For  example, 
if  an  acquisition  process  is  completed  every  week,  continuous  improvement  activities  could 
be  completed  every  quarter. 

At  this  point,  it  is  important  to  stress  that  process  improvement  group  members  should  not  be 
concerned  about  the  feasibility  of  their  redesign  proposals.  This  concern  will  only  limit  the  innovativeness 
of  the  redesign  and,  therefore,  its  effectiveness.  Redesign  feasibility  analysis  will  be  carried  out  at  a 
later  point  in  an  activity  included  especially  for  this  purpose. 
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Redesign  Stage:  Incorporate  Changes  into  the  Process 

In  this  activity,  the  facilitator  should  incorporate  the  changes  proposed  by  the  group  into  the 
process  models  and  respective  written  descriptions.  The  models  of  the  new  process  provide  feedback 
to  the  group  so  proposed  changes  can  be  discussed  and  refined  before  they  are  put  into  practice. 

Guideline 


At  this  point,  the  facilitator  should  try  to  state  who  would  be  responsible  for  implementing  the 
proposed  changes  in  the  process.  If  such  changes  need  involvement  from  higher  management  levels, 
this  should  be  clearly  stated.  Such  involvement  may  be  needed,  for  example,  for  investment  approvals 
and  certain  changes  in  the  organizational  structure. 

Redesign  Stage:  Evaluate  Redesign  Feasibility 

This  is  the  last  conceptual  activity  of  InfoDesign,  and  the  final  product  is  a  new  process  to  be 
implemented  with  the  support  of  information  technologies.  In  this  activity  the  group  members  should 
discuss  the  feasibility  of  the  changes  proposed  to  the  process  so  far  and,  if  necessary,  modify  them  to 
adapt  those  changes  to  the  reality  of  the  organization. 

Subsequent  Stages:  Implement  and  Refine  Redesign 

The  next  stages  are  the  initial  implementation  of  the  changes  and  their  refinement  so  they  can  be 
used  in  a  routine  way.  The  group  can  proceed  on  its  own  to  these  stages,  provided  that  no  involve¬ 
ment  from  higher  management  levels  is  necessary  to  implement  the  changes.  For  example,  if  the 
group  has  enough  authority  to  approve  and  support  the  changes  proposed  and  the  resources  to  carry 
this  implementation  out,  the  group  can  proceed  to  process  change  implementation  right  away.  If  the 
proceeding  is  not  the  case,  the  group  should  submit  the  change  proposal  to  those  who  are  in  a  position 
to  have  it  implemented.  Ideally,  this  should  be  done  through  the  Process  Improvement  Committee, 
which  is  the  committee  responsible  for  the  evaluation  of  redesign  proposals  and  coordination  of  their 
implementation. 
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CHAPTER  4 

THE  NEED  FOR  A  SHIFT  IN  REDESIGN  FOCUS 


A  Brief  Historical  Review  of  Business  Process  Redesign 

As  discussed  previously,  business  processes  are  sets  of  interrelated  activities  that  are  performed  to 
achieve  a  business  goal.  Business  process  redesign  dates  back  to  the  early  1900s,  when  Frederick 
Taylor  (1911)  published  The  Principles  of  Scientific  Management.  The  scientific  management  move¬ 
ment  strongly  influenced  process  redesign  ideas  and  approaches  throughout  the  Second  Industrial 
Revolution  (1850-1950).  During  this  period,  business  process  redesign  was  primarily  concerned 
with  productivity  (i.e.,  efficiency)  improvement  in  manufacturing  plants. 

The  work  of  Elton  Mayo  in  the  1930s  and  others,  such  as  McGregor,  Maslow,  and  Herzberg, 
represented  the  emergence  of  the  “humanist”  school  of  management,  which  tried  to  shift  the  focus  of 
organizational  development  from  “business  processes”  to  “people.”  While  these  management  think¬ 
ers  succeeded  in  doing  so  during  the  mid  1900s,  business  process  redesign  was  far  from  “dead.”  The 
work  of  the  “humanists”  set  the  stage  for  the  emergence  of  what  many  saw  as  a  more  “humane” 
business  process-redesign  school  of  thought.  This  new  school  of  thought,  generally  known  as  total 
quality  management,  not  only  succeeded  scientific  management  as  a  business  process-based  method 
but  also  represented  a  shift  in  focus  from  productivity  to  quality  in  the  improvement  of  business 
processes.  Total  quality  management  began  in  Japan  after  the  World  War  II.  It  was  largely  due  to  the 
work  of  William  Doming  and  Joseph  Juran  and  is  widely  credited  as  having  propelled  Japan  to 
economic  superpower  status  (Bergner,  1991;  Chapman,  1991;  Doming,  1986;  Juran,  1989;  Walton, 
1989).  In  the  1980s  it  became  widely  practiced  in  the  U.S.  and  other  Western  capitalistic  countries. 
As  with  scientific  management,  its  primary  focus  is  the  improvement  of  manufacturing  operations. 

In  the  early  1990s,  business  process  reengineering  replaced  total  quality  management  as  the  pre¬ 
dominant  school  of  thought  regarding  business  process  redesign.  Michael  Hammer  and  Thomas 
Davenport  independently  developed  business  process  reengineering  as,  respectively,  a  better  alterna¬ 
tive  (Hammer’s  version)  and  a  complement  (Davenport’s  version)  to  total  quality  management.  Total 
quality  management’s  primary  goal  is  quality  improvement,  not  productivity.  With  this  in  mind,  they 
based  their  work  on  the  premise  that  incremental  gains  in  productivity  obtained  by  implementing  total 
quality  management  were  insufficient  for  organizations  coping  with  an  accelerated  rate  of  change 
fostered  by  information  technologies  (Davenport,  1993;  1993a;  Davenport  and  Short,  1990;  Ham¬ 
mer,  1990;  Hammer  and  Champy,  1993).  Differently  from  scientific  management  and  total  quality 
management,  business  process  reengineering  was  presented  as  a  method  for  the  improvement  of 
services  as  well  as  manufacturing  operations. 

Current  Business  Process  Redesign  Practices:  A  Rehash  of  Old  Methods? 

An  analysis  of  the  business  process  redesign  practices  throughout  the  100-year  period,  from  the 
development  of  scientific  management  to  the  emergence  of  business  process  reengineering,  suggests 
an  interesting,  perhaps  cyclic,  pattern.  Even  though  processes  have  changed  significantly  since 
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Frederick  Taylor’s  times,  the  business  process  redesign  practices  employed  then  seem  very  similar  to 
those  of  the  1990s  (Kock,  1999a;  Kock  and  McQueen,  1996;  Waring,  1991). 

The  scientific  management  method  consisted  of  breaking  down  a  business  process  into  compo¬ 
nent  activities,  for  which  a  pictorial  as  well  as  a  quantitative  model  was  generated.  The  pictorial 
model  depicted  the  execution  flow  of  the  activities  and  the  associated  motions,  whereas  the  quantita¬ 
tive  model  included  information  about  physical  distances  associated  with  motions  and  the  times  needed 
to  perform  each  of  the  activities.  Taylor  showed  that  managers  could  empirically  devise  optimal  (or 
quasi-optimal)  business  process  configurations  that  could,  then,  be  standardized  through  financial 
incentives  to  workers  (Taylor,  1885;  1911). 

The  total  quality  management  movement  broke  away  from  the  productivity-only  orientation  of 
scientific  management  by  emphasizing  business  process  quality  as  the  main  goal  of  organizational 
development.  One  difficulty  faced  by  the  quality  movement  stems  from  the  fact  that  “quality”  is 
primarily  a  gauge  of  customer  satisfaction  and,  thus,  difficult  to  be  measured.  This  may  explain  the 
gradual  but  steady  emphasis  on  quality  “process”  standardization,  which  is  also  known  as  quality 
“systems”  standardization.  Total  quality  management  gradually  became  a  movement  dominated  by 
quality  process  (or  system)  standards,  such  as  the  influential  ISO-9000  set  of  quality  standards  (Arnold, 
1994).  As  such,  the  view  that  “quality  companies”  were  those  that  complied  with  quality  process 
standards  became  increasingly  widespread.  Many  view  this  as  having  pushed  total  quality  manage¬ 
ment  in  a  wrong  direction  and  into  the  hands  of  bureaucrats  who  specialized  in  quality  standards 
implementation  and  certification. 

The  dissatisfaction  created  by  the  “bureaucratization”  of  total  quality  management  and  its  alleged 
small  and  incremental  impact  on  the  “bottom-line”  of  the  companies  that  implemented  it  (Hammer 
and  Champy,  1993)  set  the  stage  for  the  emergence  of  business  process  reengineering.  Many  argue 
that  business  process  reengineering  is  a  “modernized”  version  of  scientific  management  (Earl,  1994; 
Kock  and  McQueen,  1996;  Rigby,  1993;  Waring,  1991).  The  popularity  of  reengineering  reached  its 
peak  by  the  mid-1990s  and  has  since  slumped  due  to  a  number  of  reported  failures.  James  Champy, 
a  pioneer  of  reengineering,  argued  that  70  percent  of  all  reengineering  projects  failed  to  achieve  their 
goals  (Champy,  1995).  In  spite  of  this,  reengineering  created  renewed  interest  in  business  process 
redesign,  making  it  the  most  widely  practiced  form  of  organizational  development  in  the  Year  2000. 
Business  process  redesign  in  the  New  Millennium  is  usually  conducted  in  conjunction  with  the  imple¬ 
mentation  of  enterprise  systems  and  e-business  applications  (Biggs,  2000;  Davenport,  2000;  Ham¬ 
mer,  2000). 

Current  Focus  on  Activity  Flows  and  Associated  Problems 

Unlike  the  “heyday”  of  scientific  management,  when  business  process  improvement  meant  “ma- 
terials-flow”  improvement,  information  is  what  flows  the  most  in  business  processes  today.  As  pointed 
out  by  Drucker  (1993):  “In  1880,  about  9  out  of  10  workers  made  and  moved  things;  today,  that  is 
down  to  one  out  of  five.  The  other  four  out  of  five  are  knowledge  people  or  service  workers.”  A  study 
by  Kock  and  McQueen  (1996)  shows  that,  even  in  manufacturing  organizations,  approximately  80 
percent  of  what  flows  in  business  processes  is  information,  while  the  other  20  percent  is  made  up  of 
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materials.  In  service  organizations,  this  ratio  is  usually  very  close  to  100  percent  to  0  percent.  These 
figures  seem  to  confirm  the  once  visionary  claims  that  “we  are  living  in  an  information  society” 
(Toffler,  1991)  and  that  organizations  have  become  “information  organizations”  (Drucker,  1989). 
The  high  proportion  of  information  flow  is  also  consistent  with  the  widespread  use  of  information 
technologies  in  organizations  and  its  increasing  importance  in  the  improvement  of  business  pro¬ 
cesses. 

Paradoxically  though,  most  of  today’s  business  process  redesign  practices  focus  on  the  analysis 
of  business  processes  as  sets  of  interrelated  activities,  and  little  attention  is  paid  to  the  analysis  of  the 
information  flow  in  business  processes.  The  most  widely  adopted  normative  approaches  for  business 
process  redesign  embody  general  guidelines  that  place  no  special  emphasis  on  the  redesign  of  the 
information  flow.  Thus,  the  information-intensive  nature  of  business  processes  is  discarded  (Kock 
and  McQueen,  1996).  This  is  also  true  for  the  DoD,  where  the  IDEFO  approach  for  business  process 
redesign  (Ang  and  Gay,  1993)  has  been  chosen  as  the  official  approach.  The  IDEFO  approach  is 
based  on  activity  flow  and  is  by  far  the  most  widely  used  (Dean  et  al,  1995).  One  widely  used 
activity-flow  approach  proposed  by  Harrington  (1991,  p.  108)  goes  as  far  as  stating  that:  “As  a  rule 
[information  flow  diagrams]  are  of  more  interest  to  computer  programmers  and  automated  systems 
analysts  than  to  managers  and  employees  charting  business  activities.”  (See  also  Harrington  et  al., 
1998.)  While  this  opinion  is  obviously  at  odds  with  the  notion  that  information  processing  is  the  main 
goal  of  business  processes  (Galbraith,  1977),  it  is  very  much  in  line  with  the  original  claims  of 
reengineering  (Hammer  and  Champy,  1993)  and  most  of  the  current  business  process  redesign  practice. 
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CHAPTER  5 

VALIDATING  INFODESIGN  THROUGH  AN  ACTION  RESEARCH  STUDY 


Research  Hypothesis  and  Its  Negative  Form 

Given  the  discussion  so  far  in  this  report,  it  is  reasonable  to  expect  that  business  process  redesign 
approaches  that  focus  on  the  flow  of  information  will  be  more  effective.  Thus,  they  are  preferred  by 
practitioners  over  those  based  on  the  traditional  activity-flow  view  of  processes,  simply  because  they 
will  provide  a  better  understanding  of  the  business  processes  targeted  and  a  clearer  view  of  how 
process  changes  should  be  implemented.  This  expectation,  which  is  at  the  source  of  the  development 
of  the  InfoDesign  methodology,  is  formalized  in  hypothesis  Hla  below: 


HI  a:  Business  process  redesign  practitioners  perceive  approaches  that  focus  on  information 
flow  as  more  effective  than  approaches  that  focus  on  activity  flow. 


Hlb  (negative  form  of  Hla  that  was  developed  for  hypothesis  testing  purposes): 


Hlb  (negative  form  of  Hla):  Business  process  redesign  practitioners  perceive  approaches 
that  focus  on  information  flow  as  either  less  effective  than,  or  presenting  the  same  effective¬ 
ness  as,  approaches  that  focus  on  activity  flow. 


By  providing  both  positive  and  negative  forms  of  the  hypothesis.  Popper’s  (1992)  “falsifiability 
criterion”  for  hypotheses  corroboration  could  be  used  in  this  study,  which  adds  robustness  to  the 
study’s  findings.  The  falsifiability  criterion  is  explained  in  more  detail  in  the  next  section. 

Hypothesis  Hla  and  its  negative  form,  Hlb,  were  tested  through  an  action  research  study  of  a 
business  process  redesign  project  involving  the  DoD  and  Computer  Sciences  Corporation,  a  leading 
software  provider  for  the  defense  sector.  The  project  also  involved  employees  from  Lockheed  Martin, 
a  regular  business  partner  of  the  Computer  Sciences  Corporation. 

Research  Approach  Employed:  Action  Research 

The  research  approach  employed  was  action  research  (Checkland,  1991 ;  Rapoport,  1970;  Susman 
and  Evered,  1978;  Winter,  1989);  it  was  adapted  for  the  specific  context  of  business  and  information 
technology  research  (Baskerville,  1997;  Lau,  1997;  Wood-Harper,  1985).  One  of  the  main  character¬ 
istics  of  organizational  action  research  is  that  the  researcher,  or  research  team,  applies  “positive” 
intervention  to  the  participating  organization  while  collecting  research  data  (Elden  and  Chisholm, 
1993;  Erancis,  1991;  Peters  and  Robinson,  1984).  In  this  research  project,  the  researcher  (one  of  the 
principal  investigators)  provided  business  process  improvement  training  and  facilitation  to  the  mem¬ 
bers  of  a  business  process  redesign  team  involving  employees  from  the  DoD  and  Computer  Sciences 
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Corporation.  The  facilitation  was  solely  methodological  (i.e.,  no  specific  process  redesign  sugges¬ 
tions  were  offered),  and  it  was  also  “methodologically  neutral.”  This  neutrality  prevented  biased 
perceptions  of  the  redesign  approaches  used. 

Action  research  was  employed  for  two  reasons.  First,  action  research  places  the  researcher  in  the 
“middle  of  the  action,”  allowing  close  examination  of  real-world  business  situations  in  their  full  com¬ 
plexity.  Therefore,  it  is  a  particularly  useful  research  approach  for  the  study  of  “new”  business  topics 
and  hypotheses,  such  as  those  addressed  by  this  research  study.  The  second  reason  stems  from  the  use 
of  Popper’s  “falsifiability  criterion.”  This  criterion  states  that  a  researcher  should  prove  a  hypothesis 
not  only  by  looking  for  evidence  that  supports  it  but  also  by  looking  for  evidence  suggesting  an 
exception  to  the  hypothesis  (i.e.,  evidence  supporting  the  negative  version  of  the  original  hypothesis). 
Therefore,  based  on  the  “negation”  of  Hla  in  the  previous  section,  Hlb  was  formulated.  According 
to  Popper’s  epistemology  (i.e..  Popper’s  accepted  rules  for  creation  of  valid  knowledge),  the  absence 
of  contradictory  evidence  becomes  a  strong  corroboration  of  the  original  hypothesis  (Popper,  1992). 
In  action  research,  the  researcher  is  an  “insider”  as  opposed  to  a  “removed  observer”  and,  thus,  has 
access  to  a  broader  body  of  evidence  than  in  other  research  approaches  (e.g.,  case  research,  survey 
research,  and  experimental  research).  For  this  reason,  action  research  is  particularly  effective  when 
employed  in  combination  with  Popper’s  “falsifiability  criterion.” 

The  business  process  redesign  project  focused  on  the  Computer  Sciences  Corporation,  from  whom 
the  DoD  purchased  software,  and  its  software  development  procurement  process.  The  Computer 
Sciences  Corporation  is  the  13*  largest  defense  contractor  in  the  U.S.  and  ranks  2"'*  in  information 
technology  contracts.  The  business  process  redesign  team  had  nine  members;  six  are  from  Computer 
Sciences  Corporation  and  three  from  Lockheed  Martin,  a  company  that  was  a  subcontractor  for 
Computer  Sciences  Corporation  in  many  software  development  projects.  (Lockheed  Martin  also 
regularly  subcontracted  Computer  Science  Corporation.)  DoD  members  also  participated  in  the  project 
as  information  providers  but  not  as  members  of  the  business  process  redesign  team. 

Process  Redesign  Work  and  Information-Flow  Focus 

An  analysis  conducted  by  the  business  process  redesign  team  of  the  target  process  led  to  the 
identification  of  several  problems,  including  the  following: 

•  The  work  plan  in  the  software  development  proposal  developed  for  the  DoD  often  did  not 
include  all  the  departments  that  participated  in  the  actual  work;  thus,  internal  budgeting  diffi¬ 
culties  developed. 

•  The  justification  of  the  items  in  the  Basis  of  Estimates  (BOEs)  document,  which  forms  the 
basis  on  which  the  budget  is  generated,  often  did  not  meet  the  needs  of  the  DoD. 

•  Participating  departments  were  not  informed  on  time  about  how  much  project  funding  was 
allocated  to  them;  and,  as  a  result,  they  were  often  forced  to  transfer  initial  overhead  costs  to 
other  projects. 

•  Because  there  were  no  process  metrics  in  place,  the  contracts  manager  at  Computer  Sciences 
Corporation  had  difficulty  managing  process  quality  and  productivity. 
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•  There  were  incidents  when  proposal  data  was  lost;  and,  as  a  result,  many  hours  of  work  were 
wasted.  Also,  disaster  recovery  procedures  were  not  in  place. 

The  business  process  redesign  team  employed  activity-flow  as  well  as  information-flow  model¬ 
ing  tools.  The  activity-flow  modeling  tool  used  was  the  functional  timeline  flowchart,  as  proposed  by 
Harrington  (1991)  and  Harrington  et  al.  (1998).  It  incorporated  information  about  the  organizational 
functions  involved  in  the  process  (e.g.,  contracts  manager,  program  manager,  technical  lead,  etc.),  the 
activities  carried  out  by  each  organization  function,  the  order  of  execution  of  each  activity  in  relation 
to  other  activities,  the  “process  time”  for  each  activity  (i.e.,  the  amount  of  time  required  to  perform 
each  activity),  and  the  “cycle  time”  for  each  activity  (i.e.,  the  elapsed  time  between  the  end  of  the 
activity  and  the  end  of  the  previous  activity).  See  Appendix  B  for  a  sample  functional  timeline  flow¬ 
chart  generated  by  the  business  process  redesign  team. 

The  information-flow  modeling  tool  used  was  a  modified  version  of  the  “data-flow  diagram” 
used  in  structured  systems  analysis  and  design  (Davis,  1983;  Dennis  and  Wixom,  2000),  as  proposed 
and  illustrated  by  us  in  Chapter  3  of  this  report.  It  incorporated  information  about  the  organizational 
functions  involved  in  the  process  (e.g.,  contracts  manager,  program  manager,  technical  lead,  etc.),  the 
activities  carried  out  by  each  organizational  function,  the  information  flows  between  organizational 
functions,  and  the  information  repositories  in  the  business  process.  See  Appendix  B  for  a  sample 
data-flow  diagram  generated  by  the  business  process  redesign  team. 

Without  interference  from  the  facilitator,  the  redesign  team  independently  proposed  nine  major  busi¬ 
ness  process  changes  based  on  the  redesign  guidelines  listed  in  Appendix  C.  A  content  analysis  of  the 
descriptions  of  the  proposed  changes  indicated  the  following  breakdown  according  to  their  foci: 

•  Eight  focused  only  on  the  information  flow  of  the  target  business  process  and  led  to  changes 
in  the  Request  for  Proposals  (REP)  receipt  and  announcement.  Alpha  Negotiations,  and  re¬ 
ceipt  and  announcement  of  project  awards. 

•  One  focused  on  both  the  activity  and  information  flow  of  the  target  business  process  and  led  to 
the  inclusion  of  activities  related  to  the  compilation  and  regular  review  of  process  metrics. 

The  team  generated  a  functional  timeline  flowchart  and  a  data-flow  diagram  of  the  new  pro¬ 
cess,  including  the  proposed  changes  above.  The  team  then  developed  a  “generic”  information 
technology  “solution”  (i.e.,  a  product- independent,  computer-based  infrastructure  and  system  speci¬ 
fication)  to  implement  the  new  business  process.  The  solution  was  illustrated  through  a  rich  picto¬ 
rial  representation  with  icons  representing  computers,  databases,  and  organizational  functions.  The 
redesign  team  members  saw  this  pictorial  representation  as  an  important  aid  for  them  to  use  when 
explaining  the  new  process  to  Computer  Science  Corporation  employees  and  DoD  representa¬ 
tives.  The  pictorial  representation  was  generated  entirely  based  on  the  information-flow  represen¬ 
tation  of  the  new  process. 

A  focus  group  discussion  was  conducted  with  the  members  of  the  business  process  redesign 
team  immediately  after  the  above  tasks  had  been  completed.  In  this  discussion  the  members  unani¬ 
mously  indicated  that,  based  on  their  experience  in  the  project,  a  focus  on  the  information  flow  of 
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a  business  process  was  more  likely  to  lead  to  successful  redesign  outcomes  than  would  a  focus  on 
the  activity  flow  of  the  business  process.  However,  there  was  no  consensus  on  the  reason  for  this. 
Some  suggested  that  information-flow  representations  were  easier  to  generate  than  activity-flow 
representations  of  business  processes.  Others  disagreed,  arguing  that,  while  information-flow  rep¬ 
resentations  were  more  difficult  to  generate,  they  made  it  easier  to  spot  business  process  improve¬ 
ment  opportunities. 

All  of  the  process  changes  proposed  by  the  redesign  team  were  approved  and  subsequently  imple¬ 
mented.  The  implementation  of  the  process  changes  was  accomplished  through  modifications  in  the 
computer  system  used  by  the  DoD  for  procurement.  This  computer  system  is  known  as  the  Joint 
Computer-aided  Acquisition  and  Logistics  Support  (JCALS)  system,  and  it  was  originally  developed 
by  the  Computer  Sciences  Corporation.  A  process  performance  review  conducted  approximately  6 
months  after  the  implementation  of  the  changes  indicated  that  the  business  process  redesign  outcomes 
led  to  productivity  and  quality  gains. 

Discussion  and  Conclusion 

The  evidence  from  the  business  process  redesign  project  provides  support  to  hypothesis  H 1  a  and, 
more  importantly,  fails  to  support  Hlb,  which  is  the  negative  formof  Hla.  The  most  relevant  pieces 
of  evidence  are  briefly  discussed  below: 

Hla  states  that,  “Business  process  redesign  practitioners  perceive  approaches  that  focus  on  infor¬ 
mation  flow  as  more  effective  than  approaches  that  focus  on  activity  flow.”  Key  pieces  of  evidence  in 
support  of  this  hypothesis  follow: 

•  The  business  process  redesign  team  used  only  the  information-flow  representation  to  develop 
almost  all  (eight  out  of  nine,  or  88.89  percent)  of  their  change  recommendations.  The  remain¬ 
ing  change  recommendation  was  also  based  on  the  information-flow  representation,  although 
not  exclusively. 

•  The  pictorial  representation  of  the  “generic”  information  technology  “solution”  was  generated 
entirely  based  on  the  information-flow  representation  of  the  new  process. 

•  In  the  focus  group  discussion,  conducted  with  the  members  of  the  business  process  redesign 
team  immediately  after  completion  of  the  process,  they  unanimously  indicated  that  a  focus  on 
a  business  process  information  flow  was  more  likely  to  lead  to  successful  redesign  outcomes 
than  a  focus  on  a  business  process  activity  flow. 

Hlb,  the  negative  form  of  Hla,  states  that,  “Business  process  redesign  practitioners  perceive 
approaches  that  focus  on  information  flow  as  either  less  effective  than  or  presenting  the  same  effec¬ 
tiveness  as  approaches  that  focus  on  activity  flow.”  The  following  items  suggest  a  lack  of  evidence  in 
support  of  this  hypothesis: 

•  The  business  process  redesign  team  favored  the  information-flow  representation  even 
though  it  had  generated  both  activity-flow  and  information-flow  representations  of  the 
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business  process.  Because  the  team  was  familiar  with  both  representations,  it  is  likely 
that,  if  the  team  had  perceived  both  types  of  representation  as  equivalent  in  terms  of 
effectiveness,  they  would  not  have  favored  one  over  another.  If  they  had  perceived  the 
activity-flow  representation  as  superior,  they  would  likely  have  favored  it  over  the 
information-flow  representation. 

•  Even  though  the  business  process  redesign  team  had  generated  both  activity-flow  and  infor¬ 
mation-flow  representations  of  the  new  business  process  (i.e.,  the  business  process  resulting 
from  the  change  recommendations)  the  pictorial  representation  of  the  “generic”  information 
technology  “solution”  was  based  only  on  the  information-flow  representation  of  the  new  pro¬ 
cess.  Since  the  members  of  the  redesign  team  had  both  representations  available  to  them,  it  is 
likely  that,  if  they  had  perceived  both  types  of  representations  as  equivalent  in  terms  of  effec¬ 
tiveness,  they  would  not  have  chosen  one.  Also,  they  would  not  have  referred  to  that  type  of 
representation  as  more  likely  to  lead  to  successful  results,  as  they  did  in  the  focus  group  dis¬ 
cussion.  If  they  had  perceived  the  activity-flow  representation  as  superior,  they  would  likely 
have  favored  it  over  the  information-flow  representation. 

•  One  might  argue  that  the  team  perceived  the  pictorial  representation  as  of  little  importance. 
Otherwise,  they  might  have  used  the  activity-flow  representation  as  a  basis.  Yet,  it  is  clear 
from  the  evidence  that  the  pictorial  representation  was  seen  as  very  important  by  the  redesign 
team  because  it  illustrated  how  information  technology  would  enable  the  new  process.  Also, 
the  team  saw  the  pictorial  representation  as  an  important  aid  for  explaining  the  new  process  to 
Computer  Science  Corporation  employees  and  DoD  representatives. 

When  considering  the  items  above  and  the  evidence  of  this  study,  it  seems  that  business  process 
redesign  practitioners  perceive  approaches  that  focus  on  information  flow  as  more  useful  and  effec¬ 
tive  than  approaches  that  focus  on  activity  flow. 

The  evidence  also  suggests  that  the  perceptions  above  are  warranted.  It  indicates  that  business 
process  redesign  approaches  focusing  on  information  flow  may  not  only  be  “perceived”  as  more 
effective  but  also  may  “actually”  be  more  effective  than  the  more  pervasive  approaches  based  on 
activity  flows.  The  key  reason  for  this  conclusion  is  that  the  business  process  redesign  project  studied 
was  a  successful  one.  If  the  business  process  redesign  project  had  been  unsuccessful,  the  fact  that 
practitioners  favored  one  approach  over  another  would  be  less  meaningful. 

This  study  suggests  the  need  for  a  change  of  focus  in  business  process  redesign  in  the  defense 
sector  (and  possibly  elsewhere).  The  shift  should  be  from  approaches  based  on  activity  flow  to  those 
based  on  information  flow,  such  as  InfoDesign.  Given  the  widespread  use  of  approaches  based  on 
activity  flow  today  and  their  high  rate  of  failure  (Champy,  1995;  Nissen,  1998),  such  a  change  of 
focus  may  have  a  dramatic  impact  on  future  business  process  redesign  practices  and  bottom-line 
business  impact. 
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APPENDIX  B 

ACTIVITY-FLOW  AND  DATA-FLOW  DIAGRAMS  USED 
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(Activity  names  were  iisted  next  to  the  diagram.) 
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ACTIVITY-FLOW  AND  DATA-FLOW  DIAGRAMS  USED  —  Continued 
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APPENDIX  C 

BUSINESS  PROCESS  REDESIGN  GUIDELINES  USED 


The  business  process  redesign  team  used  the  following  guidelines,  compiled  from  a  large  body  of 
literature  on  business  process  redesign.  These  guidelines  are  discussed  in  more  detail  in  Chapter  3  of 
this  report.  In  the  list  below,  the  name  of  the  technique  is  followed  by  a  brief  description  of  why  the 
technique  may  lead  to  business  process  improvement.  This  information  is  provided  here  for  quick 
reference.  (Note:  There  will  be  some  overlapping  between  the  descriptions  below  and  those  provided 
in  Chapter  3.) 

•  Foster  asynchronous  communication.  When  people  exchange  information,  they  can  do  it 
synchronously  (i.e.,  interacting  at  the  same  time)  or  asynchronously  (i.e.,  interacting  at  differ¬ 
ent  times).  One  example  of  synchronous  communication  is  a  telephone  conversation.  If  the 
conversation  takes  place  via  E-mail,  it  then  becomes  an  example  of  asynchronous  communi¬ 
cation.  It  has  been  observed,  especially  in  formal  business  interaction,  that  asynchronous  com¬ 
munication  is  almost  always  more  efficient.  For  example,  synchronous  communication  often 
leads  to  time  waste  (e.g.,  waiting  for  the  other  person  to  be  found),  and  communication  tends 
to  be  less  objective.  Asynchronous  communication  can  be  implemented  with  simple  artifacts, 
such  as  in-boxes  and  out-boxes,  fax  trays,  and  billboards.  These  artifacts  work  as  dynamic 
information  repositories. 

•  Eliminate  duplication  of  information .  Static  repositories,  as  opposed  to  dynamic  repositories, 
hold  information  on  a  more  permanent  basis.  A  student  file  maintained  by  a  primary  school,  for 
example,  is  a  static  repository  of  information.  Conversely,  the  data  entry  form  used  to  temporary 
store  student  information  that  will  be  entered  into  the  student  file  is  not  a  static  repository.  Dupli¬ 
cation  of  information  in  different  static  repositories  often  creates  inconsistency  problems,  which 
may  have  a  negative  impact  on  productivity  and  quality.  Kock  (1995)  describes  a  situation  where 
a  large  automaker’s  purchasing  division  tried  to  keep  two  supplier  databases  updated.  One  data¬ 
base  was  updated  manually  and  the  other  through  a  computer  system.  Two  databases  were 
being  kept  because  the  computer  database  had  presented  some  problems  and,  therefore,  was 
deemed  unreliable.  This,  in  turn,  caused  a  large  number  of  inconsistencies  between  the  two 
databases.  Each  database  stored  data  regarding  over  400  parts  suppliers. 

•  Reduce  information  flow.  To  the  detriment  of  effectiveness,  excessive  information  flow  is  often 
caused  by  an  over-commitment  to  efficiency.  Information  is  perceived  as  an  important  compo¬ 
nent  of  processes,  and  this  perception  drives  people  to  an  unhealthy  information  hunger.  This 
hunger  causes  information  overload  and  the  creation  of  unnecessary  information  processing 
functions  within  the  organization.  Information  overload  leads  to  stress  and,  often,  the  creation  of 
information  filtering  roles.  These  roles  are  normally  those  of  aides  or  middle  managers,  who  are 
responsible  for  filtering  in  the  important  bit  from  the  information  coming  from  both  the  bottom 
and  outside  of  the  organization.  Conversely,  excessive  information  that  flows  top-down  forces 
middle  managers  to  become  messengers  and,  thus,  damages  their  more  important  roles.  Informa¬ 
tion  flow  can  be  reduced  by  selecting  the  information  that  is  important  in  processes,  eliminating 
the  rest,  and  by  effectively  using  group  support  and  database  management  systems. 
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•  Reduce  control.  Control  activities  do  not  normally  add  value  to  customers.  They  are  often 
designed  to  prevent  problems  from  happening  as  a  result  of  human  mistakes.  In  several  cases, 
however,  control  itself  fosters  neglect  and  has  a  negative  impact  on  productivity.  For  example, 
knowing  that  there  will  be  some  kind  of  control  to  catch  mistakes,  a  worker  may  not  be  careful 
enough  when  performing  a  process  activity.  Additionally,  some  types  of  control,  such  as  those 
aimed  at  preventing  fraud,  may  prove  to  be  more  costly  than  no  control  at  all.  Some  car 
insurance  companies,  for  example,  have  determined  that  the  cost  of  accident  inspections  for  a 
large  group  of  customers  was  much  more  expensive  than  the  average  cost  of  frauds  committed 
by  that  group. 

•  Reduce  the  number  of  contact  points.  Contact  points  can  be  defined  as  points  where  interac¬ 
tion  between  two  or  more  people,  both  inside  and  outside  of  the  process,  occurs.  This  involves 
contacts  between  functions  and  between  functions  and  customers.  Contact  points  generate 
delays  and  inconsistencies  and,  when  in  excess,  lead  to  customer  perplexity  and  dissatisfac¬ 
tion.  For  example,  in  self-service  restaurants  and  warehouses,  the  points  of  contact  were  suc¬ 
cessfully  reduced  to  a  minimum.  Additionally,  it  is  much  easier  to  monitor  customer  percep¬ 
tions  in  situations  where  there  are  a  small  number  of  contact  points.  This  makes  it  easier  to 
improve  process  quality. 

•  Execute  activities  concurrently.  Activities  are  often  executed  in  sequence,  even  when  they 
could  be  done  concurrently.  This  has  a  negative  impact  primarily  on  productivity  and  is  easier 
to  spot  on  process  flowcharts  than  in  data-flow  diagrams.  For  example,  in  a  car  assembly 
process,  doors  and  other  body  parts  can  be  assembled  concurrently  with  some  engine  parts; 
and,  by  redesigning  their  processes  accordingly,  several  automakers  noted  that  the  assembly 
of  certain  car  models  was  significantly  speeded  up. 

•  Group  interrelated  activities.  Closely  interrelated  activities  should  be  grouped  in  time  and 
space.  Activities  that  use  the  same  resources  (i.e.,  artifacts  or  functions)  may  be  carried  out  at 
the  same  location  and,  in  some  cases,  at  the  same  time.  Ned  Kock  (1999)  illustrates  this  point 
using  the  case  of  a  telephone  company  that  repaired  external  and  internal  house  telephone 
connections.  This  company  had  two  teams,  one  team  performed  internal  repairs  and  the  other 
performed  external  repairs.  Internal  repairs  occur  (by  definition)  within  the  boundaries  of  a 
commercial  building  or  residence,  and  external  repairs  involve  problems  outside  these  bound¬ 
aries.  Whenever  a  customer  complaint  was  received,  the  telephone  company  sent  its  internal 
team  first.  Should  this  team  find  no  internal  connection  problem,  the  external  team  would  then 
be  dispatched  to  check  the  problem.  A  process  improvement  group  determined  that  most  of 
the  problems  were  external;  and,  by  not  combining  the  two  teams  into  a  single  repair  team,  the 
company  was  wasting  thousands  of  dollars  a  year  and  upsetting  their  customers  due  to  repair 
delays 

•  Break  complex  processes  into  simpler  ones.  Complex  processes  with  dozens  (hundreds  in 
some  cases)  of  activities  and  decision  points  should  be  “broken”  into  simpler  ones.  It  is  often 
much  simpler  to  train  workers  to  execute  several  simple  processes  than  one  complex  process. 
It  is  also  easier  to  avoid  mistakes  in  this  way  because  simple  processes  are  easy  to  understand 
and  coordinate.  In  support  of  this  point,  Ned  Kock  (1999)  presented  the  case  of  an  interna- 
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tional  events  organizer,  which  was  structured  around  two  main  processes  —  the  organization 
of  national  and  international  events.  After  a  detailed  analysis  of  these  two  processes,  which 
embodied  over  a  hundred  activities  each,  it  was  found  that  they  both  could  be  split  into  three 
simpler  subprocesses  —  the  organization  of  exhibitions,  conferences,  and  exhibitor’s  partici¬ 
pation.  This  simplification  improved  the  learning  curve  for  the  processes  and  reduced  the 
occurrence  of  mistakes.  It  did  not,  however,  lead  to  an  increase  in  the  number  of  employees 
needed  because,  with  simpler  processes,  one  person  could  perform  functions  in  various  pro¬ 
cesses  at  the  same  time. 
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